WIP: freedreno: fix point-coord origin handling
This addresses several issues:
-
ir3_point_sprite
stomped coord mode, makingGL_POINT_SPRITE_COORD_ORIGIN
no-op; - A change of
GL_POINT_SPRITE_COORD_ORIGIN
did not cause re-emission of relevant state; - PNTC seem to automatically become inverted when framebuffer is flipped (which cancels out the inversion done by gallium), while
VARYING_SLOT_TEX*
are not.
The last one is trickier. It could be reproduced e.g. with dEQP-GLES3.functional.shaders.builtin_variable.pointcoord
when launching it a) without any additional params b) with --deqp-surface-width=256 --deqp-surface-height=256 --deqp-surface-type=fbo --deqp-gl-config-name=rgba8888d24s8ms0 --deqp-visibility=hidden
Or via arb_point_sprite-checkerboard
with and without -fbo
.
Only with the HACK
commit (the same change applicable for a3xx-a5xx) all tests are passing:
arb_point_sprite-checkerboard -auto -fbo
arb_point_sprite-checkerboard -auto
gl-coord-replace-doesnt-eliminate-frag-tex-coords -auto -fbo
gl-coord-replace-doesnt-eliminate-frag-tex-coords -auto
gl-3.2-pointsprite-origin -auto -fbo
gl-3.2-pointsprite-origin -auto
gl-3.2-pointsprite-coord -auto -fbo
gl-3.2-pointsprite-coord -auto
dEQP-GLES3.functional.shaders.builtin_variable.pointcoord
It is a HACK
because I'm unsure whether I just missed something. And because I'm not sure if ctx->viewport.scale[1] < 0
is a good way to check whether framebuffer is inverted...
Also maybe we should move all calculations of vpsrepl
and vinterp
to a common helper?