util/prim_convert: Don't set index_bounds_valid

draw->index_bounds_valid tells drivers that the values of min_index/max_index are set correctly and can be used e.g. to allocate memory for varyings. If set incorrectly, the GL promises badness.

But, with primconvert, we go mucking with index buffers and then never update the bounds. So it doesn't matter if the original index bounds were valid, we can't promise the original bounds are still valid. If we were trying to optimize CPU overhead, we could try to preserve the new min/max index but seeing as only older Mali cares about this flag, and if you're using primconvert you're already screwed, I'm not too inclined to go rework primconvert.

Fixes* page faults in primitive-restart-draw-mode on Mali-G52 for GL_QUAD_STRIPS and GL_POLYGON, which hit the primconvert path. The full dmesg splat looks like:

[ 5438.811727] panfrost ffe40000.gpu: Unhandled Page fault in AS0 at VA 0x000000100A16BAC0 Reason: TODO raw fault status: 0x25002C1 decoded fault status: SLAVE FAULT exception type 0xC1: TRANSLATION_FAULT_1 access type 0x2: READ source id 0x250

Notice that a high bit is randomly set in the address, this is trying to read a varying from the actual varying buffer in the vicinity of 0xa16bac0. What's actually happening is that we're trying to read index #0 despite promising the driver a minimum index of 2, causing an integer underflow as we try to read index -2, or as the hardware sees, 4294967294.

As long as we stop lying to panfrost about the bounds being correct, panfrost is able to calculate the real (post-primconverted) bounds on its own, fixing the test.

• Alternatively, maybe Panfrost should just ignore this bit, in which I don't know why we have it in Gallium, since it's probably not conformant to fault on out-of-range glDrawRangeElements.

Signed-off-by: Alyssa Rosenzweig alyssa@collabora.com