Reading from tess.verts

[slipher]

Some renderer functions attempt to read back a surface's polygons from tess.verts. There are 3 possibilities, none of them good:

• The surface uses a static VBO with multidraw. tess.numVerts will be 0: there is nothing for it to read.
• The surface uses a static VBO with a single data range. tess.numVerts will be nonzero so the function will think there is data there. But really it is random data left over from whichever surfaces used the buffer last.
• The surface does not use a static VBO; it actually writes data to tess.verts. The function may at least work correctly in this case. But reading data from this GPU-mapped memory may cause poor performance as in Sky performance cost #849.

I haven't attempted to search for all functions like this, but happened to notice the following ones:

• SurfIsOffscreen PortalOffScreenOrOutOfRange
• AutospriteDeform
• Autosprite2Deform

Note that some "autosprite" code is already known to be broken (#730). We might detect more suspicious functions by mapping the buffer as write-only, or setting it to null when a static VBO is active.

[slipher]

Another culprit: R_GetPortalOrientations. That one also has a more serious problem: #1216.

[slipher]

For historical interest, some previous examples were fixed in f870d9f :)

[slipher]

#1444 only fixes the portal case, not the autosprite case.

[VReaperV]

#1444 only fixes the portal case, not the autosprite case.

Doesn't autosprite only write to it rather than read from it?

[slipher]

Autosprite is read-modify-write.

[VReaperV]

I thought it only reads from tess.vertsBuffer, which is supposedly CPU-side?

[slipher]

Oh right, I changed it to use the CPU buffer so that performance problem should no longer happen. It's kinda hacky but good enough to close this I guess.