On Wed, 2009-01-28 at 15:19 +0100, Roland Scheidegger wrote: > On 28.01.2009 01:50, Ian Romanick wrote: > > I'd like to propose a couple changes to our current GL and GLX extension > > policies. > > > > GL > > == > > > > There are a few GL extensions that I believe should just be made > > mandatory. Doing so would allow us to remove a ton of extension tests > > sprinkled throughout the code. The proposed extensions all provide ways > > to expose the extension without requiring additional hardware > > functionality. Enabling the extension just makes the API available. > > Here is my proposed list: > > ... > > > > - GL_ARB_vertex_program - For hardware that uses software for TNL, Mesa > > does all the work. For hardware that has only fixed-function TNL, > > vertex programs act like a TNL software fallback. Only i810, mach64, > > r128, radeon, savage, and sis do not support this extension. I believe > > that GL_NV_vertex_program and GL_NV_vertex_program1_1 should also be > > enabled. The expose nearly the same feature set as the ARB extension. > I think the concerns for enabling ARB_vp on radeons was that this might > cause programs to use a vertex program instead of using fixed function > even though they'd support the latter just fine, and the former would be > a software fallback whereas the radeon accelerates fixed function tnl. > This isn't an issue on all other chips mentioned (and it's no issue with > the tnl-less 7000/igp radeons), except performance may still be much > worse even though both tnl/vertex shaders are running in software (and > apps probably don't gain much if the chips don't support ARB_fp too).
Conceptually, I agree. However, both Nvidia and ATI have shipped ARB_vp on their fixed-function hardware (R100 and NV10) for years. Admittedly, both of those vendors have much higher performance software vertex shader support than we have. All apps that I have seen tie the use of vertex shaders with higher rendering quality. For example, they will try to use vertex shaders for per-pixel lighting paths even when the fragment path has to use ARB_texture_env_dot3. Based on my experience, a lot of these cases are faster with software shaders than with fixed-function hardware because you have to jump through fewer API hoops. > The problem with NV_vertex_program I have is that there are subtle > differences to ARB_vertex_program, specifically the need to initialize > registers to some defined values which ARB_vp leaves undefined. Not sure > if apps are really relying on this, but this adds quite some complexity > to drivers for very little gain (some generic dead code elimination > would sure help), unless this requirement is just ignored. I just don't > see much point in this extension anyway nowadays. There are two reasons for supporting NV_vertex_program. 1. There are still apps, especially closed source apps, that can use either NV_vertex_program or EXT_vertex_shader but not ARB_vertex_program. The classic example is Neverwinter Nights. I still play that from time to time. :) 2. It allows us to eliminate all the 'if (ctx->extensions.NV_vertex_program)' checks from the code. I also suspect that being able to assume vertex shader support could allow other refactoring in the code base, but that more applies to enabling ARB_vp than NV_vp. I do understand the concern about pre-initialized variables in NV_vp. I think it's reasonable to wait to enable NV_vp until after the assembly and high-level shader code generation backends are unified. Once that happens there will be no concerns about optimizing redundant initializations of variables.
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
