On Wed, 2009-01-07 at 11:48 -0800, Eric Anholt wrote: > On Wed, 2009-01-07 at 10:07 +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 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. > > We have to advertise at least 16 temps. However, the fog code eats some > of them. So we need to compress things down to hardware temps somehow, > and 32 ended up being the number of ->Index values I could handle in the > instructions with simple uint32 code. We do still end up with the > problem that someone using 32 temps and fog will exceed limits because > of how the accounting in Mesa works. > > We could also do better by throwing things that are live only between > phase boundaries into U regs instead of R regs, potentially getting us > up to 22 native temporaries live at a time. > > I understand the predictability concern for developers. But it comes > down to: Are we the exception in being unable to run shaders that the > hardware is capable of? These apps all work on ATI and NVIDIA.
It's not a big deal, just trying to illustrate the downside. It's reasonable to give it a try & see what happens. Maybe advertising a number that you're likely to have *some* chance of being able to actually translate to hardware (eg 22) in the event that a shader tries to use all available regs would make sense. Maybe it's also possible to improve Mesa's fog code? Probably not high on anybody's priority right now. 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
