Skip to content

WIP: freedreno: fix point-coord origin handling

This addresses several issues:

  • ir3_point_sprite stomped coord mode, making GL_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


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?

Edited by Danylo Piliaiev

Merge request reports