On Sat, 1 Mar 2003, Allen Akin wrote:
>
> This is largely because there's a *much* greater emphasis on performance
> in the 3D world than in the 2D world. There's too much competitive
> advantage to be gained by exposing hardware peculiarities and by
> avoiding certain kinds of abstraction.
Well, hey, that used to be the answer for 2D too. A lot of people thought
that the layering in XAA would hurt performance.
I think you're right, but I also think it's all partly because hw changes
are stil happening at breakneck speeds, and so the equation keeps on
changing on what the right layering is.
At some point that won't be true any more. And maybe it's just me, but
with programmable vertex and pixel shaders it looks like the onus is
shifting onto the _user_, and it's more likely that the hardware designs
won't be changing as radically as they used to.
> For example, it's usually too expensive (in terms of call overhead and
> data transfer/reformatting) to use layering as technique for driver
> implementation.
I'm actually not a huge fan of layering as a technique anyway - the fact
is, the upper layers just tend to do the wrong things.
But you can have high-level helper functions - things that aren't called
directly the generic layer, but that exist solely to make it easier to
build up a driver.
If and when a driver decides that they can do something better _without_
the help of generic code, it just expands the functionality itself -
without breaking anything else, and without taking the overhead of having
to go through any generic code that conditionally calls to the direct
stuff.
This is largely what the Linux kernel approach to filesystems usually is
(the exception being pathname lookup, which is just something that the VFS
layer does on its own, and the filesystem is required to play along with
the VFS rules).
So each filesystem gets to do its own "read()" however the hell it wants
to, but the VFS layer exports helper functions that 95% of all filesystems
use, and thus they don't usually actually need to do much. Almost all
filesystems use the generic_file_read() function directly, for example.
The flexibility is that the helper functions end up working more like
available templates, rather than forcing the VFS layering down the throat
of a filesystem. I think a similar approach works just about anywhere,
except it's usually _harder_ to come up with good helper functions than it
is to just force subsystems to act some way.
> Once you get rid of the legacy stuff in OpenGL, drivers are pretty much
> the same level of complexity for OpenGL as for D3D. Which is one reason
> why several groups are able to use OpenGL subsets for embedded apps.
I'll take your word for it.
Linus
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
