It seems like the ARB ProgramEnvParameter4 functions and the NV ProgramParameter4 functions should alias - they share the same glx protocol, and they are said to affect identical state in the ARB_vertex_program spec. This was reported on irc by onestone, calling ProgramEnvParameter4fv does not work with indirect rendering, but ProgramEnvParameter4dv works. If you look at the generated glx code you can see that for some odd reason one will end up calling the NV version but the other will end up calling the ARB version (indirect_table.c, opcode 4184/4185). I guess they'd need to be set to alias in gl_API.xml, and one of the functions in mesa to handle this needs to go.
Oh, and forgot to mention, does someone know why the rendering command length is specified to be 32 for ProgramEnvParameter4fvARB and friends? The values only add up to 28, which of course matches what the scripts generate. Is this an error in the spec?
Created attachment 12282 [details] [review] patch to alias ProgramEnvParameter4xyARB and ProgramParameter4xyNV Here's a quick stab at the problem (obviously not including all the files which need to be recreated). I think it might break NV_vertex_program, because I thought I should make ProgramParameter4xyNV an alias to ProgramEnvParameter4xyARB in gl_API.xml but that didn't work (the scripts didn't generate the non-vectorized versions in this case for the glx code).
Created attachment 12301 [details] [review] more correct patch this patch doesn't completely nuke nv vertex programs. This is what I originally did. The glx code generated will be missing the 4fARB and 4dARB functions (only 4fvARB and 4dvARB). Looks like an ordering issue, it'll have all 4 functions (4fNV, 4fvNV, 4dNV, 4dvNV) in the generated glx code if the aliasing is reversed. Not sure if that's a bug or a feature of the scripts....
(In reply to comment #3) > Not sure if that's a bug or a feature of the scripts.... It was a bug. See commit d34caddb4e62296f80792998ce0a42b07f919361. Your patch now generates the correct code. Go ahead and commit it when you get the chance.
(In reply to comment #4) > (In reply to comment #3) > > Not sure if that's a bug or a feature of the scripts.... > > It was a bug. See commit d34caddb4e62296f80792998ce0a42b07f919361. Your patch > now generates the correct code. Go ahead and commit it when you get the > chance. Thanks Ian. Pushed.
Mass version move, cvs -> git
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.