On Tue, Jul 10, 2012 at 3:30 PM, Jose Fonseca <jfons...@vmware.com> wrote: > Yep. The interfaces are busted. > > Without native integers we get > > DCL SV[0], INSTANCEID > ... > ARL ADDR[0].x, SV[0].xxxx > > and with integers we get > > DCL SV[0], INSTANCEID > ... > UARL ADDR[0].x, SV[0].xxxx > > Olivier's fix is incorrect. It works on the above cases by guessing the type, > but if we have: > > DCL SV[0], INSTANCEID > ... > MOV TEMP[0].x, SV[0].xxxx > ARL ADDR[0].x, TEMP[0].xxxx > > and > > DCL SV[0], INSTANCEID > ... > MOV TEMP[0].x, SV[0].xxxx > UARL ADDR[0].x, TEMP[0].xxxx > > it is impossible to guess -- the change is merely replacing a bug with > another. > > > For the record, the problem also happens without LLVM: > > DRAW_USE_LLVM=0 draw-instanced -auto > > > > Anyway, AFAICT, all hardware out there that really supports > INSTANCEID/VERTEXID also supports native integers, so this is a problem > specific to the draw module. > > But given that draw module can support anything, this is actually self > inflicted! In short, INSTANCEID/VERTEXID without integers is an historic > artifact, that should not exist going forward. > > The right fix is merely making sure that PIPE_SHADER_CAP_INTEGERS is > accurately advertised as 1 by the draw module (just like Stephane secretly > did in 45fc069600ddbfe07a0a0cd5280161a8c7c55dd0 :)
I just wanted to tell you Stephane's change cannot work and it even has no effect at the moment. The native integer support is global in core Mesa. It's because integer uniforms are converted to floats based on the global NativeInteger flag for all shader stages and that can't be fixed easily, because uniforms can be shared between shaders. Basically, all drivers must advertise integer support either for all shader stages or none. Given that, I only see two possible outcomes: 1) Disable INSTANCEID support in DX9-level drivers using Draw (that's only i915g AFAIK) and only support INSTANCEID with integers. 2) Let drivers set the type of system values in Draw, so that Draw doesn't have to guess what it should be. I'm okay with either solution. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
