e.g. bridge of fate.
If vs output is big, driver may fall back to use 8 urb entries for vs,
unfortunally, for some unknown reason, if vs is working at 4x2 mode,
8 entries is not enough, may lead to gpu hang.
Makes state emission into a 2 phase, prepare sets things up and accounts
the size of all referenced buffer objects. The emit stage then actually
does the batchbuffer touching for emitting the objects.
There is an assert in dri_emit_reloc if a reloc occurs for a buffer
that hasn't been accounted yet.
So with compiz on Intel hw with fake bufmgr, opening 4 firefox windows at 1680x1050 and hitting alt-tab, could cause the batchbuffer to try and reference more than the 32MB of RAM allocated.
Fix 1:
Fix 1 is to pre-verify the list of buffers against the current batchbuffer and if it can't possibly fit in the aperture to flush the batchbuffer to the hardware
and try again. If the buffers still can't fit well then you are hosed as I'm not sure there is a nice way to tell anyone.
Fix 2:
Next problem was that even with a simple check for total < aperture, we ran
into fragmentation issues, this meant that half way down a set of buffers,
we would fail as no blocks were available. Fix this by nuking the memory
manager from orbit and letting it start again and relayout the blocks in a
manner that fits.
Fix 3:
Finally the initial problem we were seeing was a memcpy to a NULL backing store.
We seem to end up with a texture at some point that never gets mapped but ends up with data in it. compiz al-tab icons have this property. So I created a card dirty bit that memcpy's any buffer that is !static and is written to back to memory. This probably is wrong but it makes compiz work for now.
Caveats:
965 support is still fail.
due to the two read ports limit into temp memory may need the MAD_2 instruction
for the second instruction of the decomposed XPD.
While here, also try to avoid MAD_2 for MAD if all 3 inputs are temps but the
temps aren't actually distinct.
Fixes compiz with direct rendering when both GLX_TEXTURE_2D_EXT and
GLX_TEXTURE_RECTANGLE_EXT are supported for a GLXPixmap and the
application didn't specify the texture target as a GLX drawable attribute
when creating the GLX drawable.
George Sapountzis
Alan Hourihane
Xiang, Haihao
Zou Nan hai
Eric Anholt
Dave Airlie
Dave Airlie
Andrew Randrianasulu
Brian
David Flynn
Roland Scheidegger
Michel Dänzer
Hasso Tepper
Jie Luo
Kristian Høgsberg