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:
parent
e8d40eb136
commit
5e874c650c
@ -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);
|
||||
|
@ -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);
|
||||
|
Loading…
Reference in New Issue
Block a user