On Thu, 2012-01-05 at 15:29 -0500, Alex Deucher wrote: > 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. >
OK, I'll implement it in the shaders. Vadim > 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
