On 4 October 2011 14:49, Brian Paul <bri...@vmware.com> wrote: > On 10/04/2011 03:19 PM, Paul Berry wrote: > >> On 4 October 2011 13:15, Ian Romanick <i...@freedesktop.org >> <mailto:i...@freedesktop.org>> wrote: >> >> On 10/03/2011 02:17 PM, Paul Berry wrote: >> >> Before this patch, clip planes didn't work properly in Mesa >> when using >> vertex shaders, because Mesa assigned both gl_ClipVertex and >> gl_Position to the same gl_vert_result (VERT_RESULT_HPOS). As a >> result, backends couldn't distinguish between the two >> variables, so >> any shader that wrote different values to them would fail to work >> properly. >> >> This patch paves the way for proper support of gl_ClipVertex by >> creating a new enumerated value in gl_vert_result for it >> (VERT_RESULT_CLIP_VERTEX). After this patch, a back-end may add >> >> >> What happens in drivers that aren't expecting / don't know about >> VERT_RESULT_CLIP_VERTEX? In other words, does this break (more) >> i915 and all Gallium drivers? I understand that gl_ClipVertex >> already doesn't work anywhere, but it would be a shame to replace >> incorrect rendering with a crash. >> >> I can test out (and patch up) i915 today, but I'd like some >> feedback from people that rely on TGSI. >> >> >> Dang, I should have thought of this. >> >> BTW, an easy way to assess the effect of this patch on a driver would >> be to run Piglit with "-t clip" after applying this patch. The patch >> should only regress "vs-clip-vertex-const-reject" (which only used to >> pass by dumb luck), and nothing should crash or abort. Also, if >> "clip-plane-transformation fixed" passes, we can have pretty high >> confidence that old fashioned fixed function clipping still works. >> >> I just did this test on Gallium's LLVM pipe and on vanilla swrast, and >> everything looked ok--no regressions other than >> vs-clip-vertex-const-reject. BTW, both gallium LLVM pipe and vanilla >> swrast have a crash (in "vs-clip-vertex-enables" and >> "clip-plane-transformation arb", respectively), but in both cases the >> crash seems to be unrelated to this patch. >> > > Can you show me the command lines to run these? I can't find > vs-clip-vertex-enables
Oh yeah, some of those tests haven't landed yet--they're in a 3-patch series I sent to the Piglit list yesterday afternoon. If one of you wants to give me a "Reviewed-by" on the Piglit list I'll commit them to master. In the meantime you can get them from branch "clip-plane-transformation" on git:// github.com/stereotype441/piglit.git. > > > > Unfortunately I don't have the hardware to test anything else so I'd >> appreciate feedback from others. >> >> If worse comes to worst and we do wind up regressing a driver, I >> suppose a workaround would be to add a flag to >> gl_shader_compiler_options so that the driver can tell the GLSL >> compiler either "I understand VERT_RESULT_CLIP_VERTEX" or "I don't, >> just do the old buggy behavior". But it seems ugly so I would rather >> avoid that sort of thing if we can. >> > > Gallium doesn't support clip distances yet so we might have to work on > that. If you've tested llvmpipe and it looks OK, that's enough for me at > this point. > > -Brian >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
