Microsoft is to overhaul Windows' graphic driver model after realising that the one that will ship with Windows Vista - Windows Display Driver Model (WDDM) 1.0 - needs improvement in the way it shares GPU resources between programs and Windows itself.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-06
Check this paper out too. These guys provided source code for Linux.
http://staffwww.itn.liu.se/~stegu/GLSL-conics/
Long run antialiasing on the GPU is always going to win. To get it right it needs to be done as late in the drawing process as possible. It is completely parallel, perfect for shader programs.
Sooner or later someone is going to write an open, sub-pixel antialiased, GPU-based glyph generator. VTM was a start but no source and there are probably more efficient ways to do it. There is no reason that GPU generated glyphs won't equal freetype quality sooner or later.
Member since:2005-07-06
Thanks, the link to http://www.beyond3d.com/articles/wildcatiii/index.php?page=page4.in... was real eye openner, I used magnify to examine the gifs closely and can really see the diffirence, not to mention the mess the KYROII's 4X FSAA did to the image.
For some reason I did not think of context switching of the GPU. I guess I am still thinking in 2D mode where you don't need that much info to draw something on the screen. A true 3D screen needs a lot more info to describe the contents of a window and swapping it around must be a pain.
Again thanks for the reply.
Member since:
2005-07-06
That's exactly what Longhorn (and likely OS X 10.5) will do. However, that brings up the central problem that is being addressed in that article: how to handle sharing of the GPU.
In consumer software, the GPU is shared in a very heavyweight way. Basically, to switch from thread A's OpenGL context to thread B's OpenGL context, the driver idle's the GPU (ie: waits for all current command buffers to finish processing), then saves and restores a fairly large amount of register state. This is okay when the only OpenGL client is a game or 3D modeler, but breaks down when a dozen apps all want to render via the GPU.
At that point, you need to virtualize the GPU, like you do the CPU, and implement scheduling mechanisms so you can put some bounds on how long a context-switch might take or how long a graphics thread might have to wait before getting a chance to render. There are two ways to do this, analogous to how there are two ways to handle multiple apps using the sound-card simultaniously. You can either mix the command streams in software at a high level (eg: XGL takes multiple RENDER command streams and muxes them to a single GL command stream), or in the driver at a low level (eg: hardware takes in multiple GL command streams, and switches between them using hardware support).
There is also a somewhat tangential reason to not use the GPU for drawing window buffers. Current GPUs don't do anti-aliasing very well. 4x multisampling is about the highest you can go with good performance, and while that may be okay for a game, it looks pretty crappy for high-contrast vector image. A rather stark depiction of the difference in anti-aliasing quality can be seen here: http://www.beyond3d.com/articles/wildcatiii/index.php?page=page4.in...
Note that in the close-up on the second page, even the Wildcat with 16x AA is still only using 16 levels of gray to perform the anti-aliasing. In contrast, FreeType uses 256 levels of gray when anti-aliasing fonts.
Microsoft has solved this particular issue in a very elegant way using vector textures (http://research.microsoft.com/~cloop/LoopBlinn05.pdf, http://alice.loria.fr/publications/papers/2005/VTM/vtm.pdf), but I'm not aware of any work on-going to implement something like this in OS X or XGL.