On Thu, Jan 5, 2012 at 3:06 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 05.01.2012 17:27, schrieb Alex Deucher: >> On Thu, Jan 5, 2012 at 11:10 AM, Andre Maasikas <amaasi...@gmail.com> wrote: >>> On Thu, Jan 5, 2012 at 4:58 PM, Marek Olšák <mar...@gmail.com> wrote: >>>> On Thu, Jan 5, 2012 at 9:13 AM, Vadim Girlin <vadimgir...@gmail.com> wrote: >>>>> Rendering in two-sided mode is performed in separate passes for front and >>>>> back faces, corresponding colors are selected by semantic ids. >>>> >>>> Are you sure that r600 cannot do two-sided color selection in >>>> hardware? I find it really surprising. >>>> >>> Not fully automatically afaik, but i guess one can load facing bit >>> (FRONT_FACE_ENA?) >>> into PS and from there on decide which color to use. This would however >>> require >>> shader rewrite/modification >>> >> >> I'll ask the hw guys. > > I think it would make some sense if the hw didn't support this directly. > After all newer APIs always work like that (face register and > appropriate pixel shader). > If the hw can't do it I think shader modification is definitely the way > to go (and the svga driver does this). Maybe the state tracker could do > it (optionally of course) if several different hw is affected (or some > utility function somewhere). Though it might be some work to get it > right (I think for instance you can't have more than 2 color input regs > in the pixel shader, hence if you have both specular and diffuse > front/back colors some values need to be texcoords).
I just confirmed internally that the face selection has to be done in the shader. So you'd set SPI_PS_IN_CONTROL_1.FRONT_FACE_ENA, etc. to get the face info into a gpr in the pixel shader. If you calculate the lighting in the vertex shader, you'd need to export both results to the pixel shader and then use the face info to select the appropriate one. r6xx+ hardware doesn't have specific color/texcoord slots, it just has 32 generic param slots that can be used to pass data from the vertex shader to the pixel shader. The hw will do semantic matching of params however (e.g., the vertex exports will be loaded into pixel GPRs based on the semantic ids assigned to them. Alex > > Roland > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
