This is a hack.

Since mesa changed some code, GL applications have been rather nasty to
the xserver, if they are unconstrained rendering wise they spam too many
requests at the xserver and make it slow as hell (even if the cpu is
fairly idle).

There is a throttling mechanism in the xserver (1.8 at least), but that
only really works if you are doing vblank syncing (which is turned off
in our intel driver right now for unrelated reasons), and even then an unsynced
client can cause the same problem.

While a proper fix is being worked on (I am in discussion with X
developers), comment out two conditionals in the intel mesa driver so
that even when using dri2 swapbuffers we wait on the swapbuffers before
last before rendeing more, this prevents almost DoSing the server.

Tested on ironlake, 855 and 965 by me (and my matthieu as well). ok
matthieu@
This commit is contained in:
oga 2010-07-24 18:13:33 +00:00
parent e8d40eb136
commit 5e874c650c
2 changed files with 2 additions and 2 deletions

View File

@ -130,7 +130,7 @@ _intel_batchbuffer_flush(struct intel_batchbuffer *batch, const char *file,
struct intel_context *intel = batch->intel;
GLuint used = batch->ptr - batch->map;
if (!intel->using_dri2_swapbuffers &&
if (/* !intel->using_dri2_swapbuffers && */
intel->first_post_swapbuffers_batch == NULL) {
intel->first_post_swapbuffers_batch = intel->batch->buf;
drm_intel_bo_reference(intel->first_post_swapbuffers_batch);

View File

@ -529,7 +529,7 @@ intel_glFlush(GLcontext *ctx)
* and getting our hands on that doesn't seem worth it, so we just us the
* first batch we emitted after the last swap.
*/
if (!intel->using_dri2_swapbuffers &&
if (/* !intel->using_dri2_swapbuffers && */
intel->first_post_swapbuffers_batch != NULL) {
drm_intel_bo_wait_rendering(intel->first_post_swapbuffers_batch);
drm_intel_bo_unreference(intel->first_post_swapbuffers_batch);