On Wed, 2009-01-07 at 12:08 -0800, Ian Romanick wrote: > 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.
Ah cool. No problems in that case... Keith ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
