Zack, to be honest, Direct3D 11 can report geometry shaders are not supported through so-called feature levels. There are six levels to my knowledge (9_1, 9_2, 9_3, 10_0, 10_1, 11_0). i915 is 9_1, R300 is 9_2, R500 is 9_3, and so on. Direct3D 11 is indeed accelerated on those pieces of hardware and, though the feature set is a little limited, the hardware support is covered well. Is Direct3D 11 generations past because of that? No, it isn't.
Let's say I have R500 and I want to use geometry shaders in Direct3D 11. What are my options? I can't use my R500 and I must manually switch to the device called WARP (Windows Advanced Rasterization Platform), which reports the 10_1 feature level. This kind of device is very similar to llvmpipe in Gallium. In the past you said we should do it the same way as Direct3D, so why should Gallium be different now? Moreover, if applications decide to use geometry shaders to emulate point sprites or wide lines, we'll be screwed. If they decide to do texture fetches in geometry shaders, we'll be screwed even more because we'll have to move textures out of VRAM and that will be a total performance killer. So I agree with Corbin that the CAP for geometry shaders should be added and we should let drivers decide what's best for them. Marek On Fri, Dec 25, 2009 at 5:11 PM, Zack Rusin <za...@vmware.com> wrote: > On Friday 25 December 2009 07:03:02 Corbin Simpson wrote: > > Isn't this incredibly at odds with our previous discussion, in which > > we generally agreed to not advertise support for unaccelerated things? > > No, it's really not. We don't have caps for core features, e.g we don't > have > caps for vertex shaders and this goes hand in hand with that. Geometry > shaders > are optional in the pipeline meaning that unlike fragment shaders they can > be > absent in which case the pipeline behaves just like it would if the api > didn't > have geometry shaders exposed at all i.e. vertex shader outputs go directly > do > the fragment shader. So for games/apps that don't use geometry shaders this > won't matter at all. And games/app that are so new that they actually check > for geometry shaders will already be slow on i915 and r300 not because of > geometry shaders, but because they're running on it on i915 or r300 =) > > Not to mention that this is not a fringe feature that will be present only > in > super high-end and futuristic hardware. > > All in all it's a bit like fixed-point hardware - programmable hardware is > not > a cap because it's what Gallium models. We can't just keep the Gallium > interface at i915 level and mark everything above that as a cap, it'd be > silly > given that we're generations past that now. > > z > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev >
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
