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 
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 

>  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.


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
Mesa3d-dev mailing list

Reply via email to