On Wed, Jan 07, 2009 at 10:07:44AM +0000, Keith Whitwell wrote: > On Wed, 2009-01-07 at 01:49 -0800, Eric Anholt wrote: > > Here's a pair of patches I came up with tonight when looking at #18074 and > > #14503. The first looks like we might end up with junk in a temporary if > > we wrote it, did a masked texld, then wrote to it again with a destination > > write mask. > > > > The second creates a mapping from register->Index to hardware temporary > > registers. I don't have the apps in question, so I haven't tested it. > > Searching for people reporting the message came up with these two bug > > reports > > plus cube, and I found that sauer did trigger it. However, sauer still > > fails > > on a bunch of its shaders due to texture indirections, so I can't place > > accurate blame for the nasty rendering I see. > > Is the purpose of the second patch to advertise more temps than the > hardware actually supports & then try and wiggle them all into hw regs > by identifying live vs non-live regs? > > I guess one worry is that advertising greater capabilities than really > exist may encourage some apps to switch to more complicated shaders > (that really can't be squeezed into hardware) and end up on fallback > paths where previously they would have been fine.
I think the way he did it follows the rules and the spirit of the spec. There are two queries available: MAX_PROGRAM_TEMPORARIES_ARB and MAX_PROGRAM_NATIVE_TEMPORARIES_ARB. The former is the maximum number of temporaries that the problem can use in its source. The later is the maximum number of temporaries that can be used after the driver has compiled the program. The intention was that MAX_PROGRAM_TEMPORARIES_ARB >= MAX_PROGRAM_NATIVE_TEMPORARIES_ARB for exactly this purpose. Apps with really optimized register usage should know to use the later to determine which shader to load. Moreover, apps should know to try a complex shader and, if glProgramStringARB fails, use a different shader. Guess and check FTW. :( As an added data point, Apple advertises MAX_PROGRAM_TEMPORARIES_ARB = 65536 on all hardware. MAX_PROGRAM_NATIVE_TEMPORARIES_ARB is set to the actual hardware limit. http://developer.apple.com/graphicsimaging/opengl/capabilities/ > I don't have specific examples to hand, but there have been equivalent > issues in other situations -- if an app sees a certain capability > advertised, it doesn't have any way of knowing that it only works under > some circumstances & not others. See issue #36 in the ARB_vertex_program spec. If the application tries to load a program that won't work with the hardware, glProgramStringARB fails. (36) How should this extension provide feedback on why a program failed to load? RESOLVED: Two queries are provided. Calling GetIntegerv() with PROGRAM_ERROR_POSITION_ARB provides the offset of an offending instruction in the program string. An error position of -1 indicates that a program loaded successfully. Calling GetString() with PROGRAM_ERROR_STRING_ARB returns an implementation-dependent error string explaining the reason for the failure. The error string can be queried even on successful program loads to check for warning messages. The error string may be kept in a static buffer managed by the GL implementation. Implementations may reuse the same buffer on subsequent calls to ProgramStringARB, so returned error strings are guaranteed to be valid only until the next such call.
pgpSeB8CnMPVK.pgp
Description: PGP signature
------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB
_______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
