On Thursday, March 05, 2015 09:39:58 PM Jason Ekstrand wrote: > This looks fine to me. I just kicked off a build on our test farm and, > assuming that looks good (I'll send another e-mail in the morning if it > does), > > Reviewed-by: Jason Ekstrand <jason.ekstr...@intel.com> > > I ran shader-db on the change and I was kind of surprised to see that it > doesn't really do anything. > > GAINED: shaders/dolphin/smg.1.shader_test FS SIMD16 > > total instructions in shared programs: 5769629 -> 5769629 (0.00%) > instructions in affected programs: 0 -> 0 > helped: 0 > HURT: 0 > GAINED: 1 > LOST: 0 > > Perhaps shader-db doesn't account for some other GL state required for > dual-source because I doubt only one shader uses it. Ken? > > --Jason
That would be dolphin/smg.1.shader_test - the one lonely shader that uses layout qualifiers to specify the dual source color output index: layout(location = 0, index = 1) out vec4 ocol1; Other applications (such as Unigine) most likely call glBindFragDataLocationIndexed to assign the location and index. Unfortunately, shader-db doesn't capture this, as it's tied to API calls, and not part of the shader itself. Eric's new shader-db-2 project that uses apitrace would catch this (but at a large cost). We could probably capture this somehow - add some kind of annotations to the file with the locations/indexes of each shader input/output, then make the API calls after compiling the shader...relink to make them take effect, which would also cause a new precompile, then replace the original results...seems like a pain, but probably doable...
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev