[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
"Frederic A . Martinelli" wrote:
> I would like to add to that thread that, by now, there is another problem
> for a game company who would be interested in making games for Linux: 3D.
> We all know in this mailing list that without proper 3D support there is
> not, at (short?/)medium/long term, a market for the gaming industry under
> With the `curious' thing SGI have done 6 months ago, i'm not sure anyone
> knows by now, for sure, if OpenGL will last, let say, up to the end of
> this year. I hope to be wrong here, but we are talking about a M$ move
> here, not about a Santa Claus' one and it's 62.5M$US, not a couple of
Yes - that's a very worrying thing.
> I do believe this rises a big problem that we need to fix as fast as
> possible: will software rendering be able to be seen as an alternative to
> hardware rendering ? In any way: final look, speed, etc...
No - no way - hardware rendering is absolutely essential to 'modern' games.
I mean, yes you could still write Tetris - but anything remotely similar
to the games people are actually buying these days has to push the hardware
> If the reply is no for the end user, then hope is small.
Well, the hope is that they really *are* buying these patents to avoid
future legal action rather than putting OpenGL out of business.
But - Microsoft is Evil and the US government has evidently decided to
allow them to continue being evil - so I suppose that anything is possible.
> What is interesting here is `end user'... Those who buy games.
> (By speed i don't expect 150fps, but the 30 required for smooth playing.
> Yes i know one can play at 6, but i was talking about real playing not
> `with cup of tea' playing.)
> Really are there any people out there still able to code asm the way we
> were doing it on the Amiga up to 486s ? Personnally i don't even remember
> how to do affine texture mapping by hand or mipmapping... Really someone
> knows of a `3D 30fps when under load library' under Linux ?
Going back to writing assembler code isn't going to help. Hardware rendering
(at the pixel level) is at least 100 times faster than the best that software
can do - possibly 500 times faster. At the polygon level, the factor is even
greater. A modern graphics card can push 10 million triangles per second.
Software transform & lighting never got much beyond 10 *thousand*...and that's
without things like vertex programs which add considerable sophistication
to the process.
The problem is fundamental. There are more transistors in an nVidia GPU
than in a Pentium IV. Almost all of the nVidia transistors are switching
all the time where most of them in the Pentium are in the Cache memory
which is static most of the time. This is because:
a) A GPU is a dedicated device that's designed for one job and one job
only. It can be heavily optimised. A CPU is the ultimate generalist
and much of it's circuitry is dedicated to things you don't need while
you are doing graphics.
b) It's very hard to add parallelism into a CPU because programs run instructions
sequentially. But in a graphics chip, you can do things like render dozens of
pixels in parallel. That makes the problem much more scaleable.
Given that, you can't ever hope to come close to the 3D performance of hardware
OpenGL using software. It's not the difference between 150Hz and 30Hz - it's
the difference between 150Hz and one frame every three seconds.
If Microsoft manage to shut down OpenGL for Linux, we are basically doomed.
----------------------------- Steve Baker -------------------------------
Mail : <firstname.lastname@example.org> WorkMail: <email@example.com>
URLs : http://www.sjbaker.org
http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
- RE: Loki...
- From: "Green, Aaron" <JAGREEN@GAPAC.com>
- Re: Loki...
- From: "Frederic A . Martinelli" <firstname.lastname@example.org>