On Saturday 26 December 2009 02:19:40 Marek Olšák wrote: > 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?
I think you're using "it" a bit broadly here because we never had a discussion about caps. First of all Gallium3D is already different when it comes to capabilities reporting. We have a buttload of caps, realistically speaking most of them are likely tight together. What we do right now is what d3d9 used to do which is what everyone agreed is awful. Not to mention that we don't have an option of actually selecting llvmpipe vs whatever hardware driver by hand. The argument that would certainly make sense is one for moving Gallium3D caps model towards a shader-model reporting. e.g. shader-model 2.x, 3.x, 4.x, 5.x versus every single feature that they bring forward, e.g. 4.x implies geometry shader, 5.x implies tessellation/compute. I absolutely abhor the idea of reporting as a cap everything above of what i915 or r300 can do, for the lack of better wording it's just ridicules. I do think though that we should look at our caps bits and come up with something better. > Moreover, if applications decide to use geometry shaders to emulate point > sprites or wide lines, we'll be screwed. If the hardware doesn't implement those features they'll be in the draw module anyway. So it's really draw module vs draw module. > 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. How is that different from the same problem applied to a vertex shader on i915 and the ways that works right now? I agree that we need to solve that problems, but I just refuse that the best we can is "everything above i915 is a feature cap". We need to come up with a scheme that actually works or assume it's ok for draw module to handle some of those features. For us it likely should be some combination of API and shader-model support (shader-models don't tell us anything about gl specific features like shadow samplers or aa lines/points), if we can figure out we can reasonable handle that we'll be fine. 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
