Bug 99555 - LIBGL_ALWAYS_INDIRECT=1 causes all opengl programms to crash on second frame
Summary: LIBGL_ALWAYS_INDIRECT=1 causes all opengl programms to crash on second frame
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Ext/GLX (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-26 20:40 UTC by diplosarus
Modified: 2018-08-06 12:32 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description diplosarus 2017-01-26 20:40:44 UTC
LIBGL_ALWAYS_INDIRECT=1 glxgears 
fails on latest git on r600 with:

X Error of failed request:  255
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  1 (X_GLXRender)
  Serial number of failed request:  42
  Current serial number in output stream:  164

After rendering one frame. this is on a ATI HD5850. This is 100% repeatable and occures with every opengl app. Direct Rendering works fine. 

Indirect rendering works with the vesa x11 driver and llvmpipe. xf86-video-ati versus xf86-video-modestetting both fail.
Comment 1 Michel Dänzer 2017-01-27 08:23:43 UTC
This code in __glXForceCurrent:

    if (cx->wait && (*cx->wait) (cx, cl, error))
        return NULL;

calls DRI2WaitSwap, which returns TRUE because there is a pending swap. I suspect something to deal with this went missing at a higher level at some point.
Comment 2 diplosarus 2017-01-29 23:35:31 UTC
Xorg 1.18.3 and below works fine, xorg 1.18.4 fails.
Comment 3 diplosarus 2017-01-29 23:42:57 UTC
Looking at the commits between 1.18.3 and 1.18.4 this commit seams pertain to the case: https://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.18-branch&id=54ba95861e5ae54051d3963e5e7ced7d69a6de7b
Comment 4 Michel Dänzer 2017-01-30 01:04:20 UTC
(In reply to diplosarus from comment #3)
> Looking at the commits between 1.18.3 and 1.18.4 this commit seams pertain
> to the case:
> https://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.18-
> branch&id=54ba95861e5ae54051d3963e5e7ced7d69a6de7b

Does reverting that commit fix it?
Comment 5 diplosarus 2017-03-20 11:18:34 UTC
(In reply to Michel Dänzer from comment #4) 
> Does reverting that commit fix it?

No sadly not.

Also this bug Persists in 1.19.3
Comment 6 Michel Dänzer 2017-03-22 09:18:00 UTC
Can you bisect between 1.18.3 and 1.18.4?
Comment 7 Kusanagi Kouichi 2018-02-09 13:31:48 UTC
I tested with xf86-video-ati-7.10.0-23-g733f606d. xorg-server-1.18.4 is good and xorg-server-1.19.0 is bad. Bisected and the result is:


7d33ab0f8c7958b205076f71e4b47c24aace77fd is the first bad commit
commit 7d33ab0f8c7958b205076f71e4b47c24aace77fd
Author: Adam Jackson <ajax@redhat.com>
Date:   Tue Jun 28 15:54:44 2016 -0400

    dri2: Don't make reference to noClientException

    noClientException is now never filled in with a meaningful value, it's
    always -1. The sole caller of this function disregards the error value
    in any case.

    Reviewed-by: Eric Anholt <eric@anholt.net>
    Signed-off-by: Adam Jackson <ajax@redhat.com>

:040000 040000 50ecf07fd43345192f937697193acbc91086e975 6d6494a0a06aed80c78491b758f7e35bf3059389 M      glx


Without 7d33ab0f8c7958b205076f71e4b47c24aace77fd, xorg-server-1.19.0 works but xorg-server-1.19.0-587-gbebcc8477 doesn't work. No X error but the following errors in dmesg:
[1654246.207734] radeon 0000:00:01.0: bo ffff90626cd73000 don't has a mapping in vm ffff90624f11d200
[1654246.212430] radeon 0000:00:01.0: bo ffff90626cd73000 don't has a mapping in vm ffff90624f11d200
[1654246.220569] radeon 0000:00:01.0: bo ffff90626cd73000 don't has a mapping in vm ffff90624f11d200
[1654246.220790] radeon 0000:00:01.0: bo ffff90626cd73000 don't has a mapping in vm ffff90624f11d200
[1654246.220880] radeon 0000:00:01.0: bo ffff90626cd73000 don't has a mapping in vm ffff90624f11d200
[1654246.236924] radeon 0000:00:01.0: bo ffff90626cd73000 don't has a mapping in vm ffff90624f11d200
[1654246.237176] radeon 0000:00:01.0: bo ffff90626cd73000 don't has a mapping in vm ffff90624f11d200
[1654246.237255] radeon 0000:00:01.0: bo ffff90626cd73000 don't has a mapping in vm ffff90624f11d200
[1654246.248485] radeon 0000:00:01.0: bo ffff90626cd73000 don't has a mapping in vm ffff90624f11d200
[1654246.248810] radeon 0000:00:01.0: bo ffff90626cd73000 don't has a mapping in vm ffff90624f11d200
[1654246.248960] radeon 0000:00:01.0: bo ffff90626cd73000 don't has a mapping in vm ffff90624f11d200
[1654246.265295] radeon 0000:00:01.0: bo ffff90626cd73000 don't has a mapping in vm ffff90624f11d200
[1654246.265866] radeon 0000:00:01.0: bo ffff90626cd73000 don't has a mapping in vm ffff90624f11d200
[1654246.266024] radeon 0000:00:01.0: bo ffff90626cd73000 don't has a mapping in vm ffff90624f11d200
[1654246.281986] radeon 0000:00:01.0: bo ffff90626cd73000 don't has a mapping in vm ffff90624f11d200
[1654246.992998] [drm:radeon_cs_parser_relocs [radeon]] *ERROR* gem object lookup failed 0x4c
[1654246.993025] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse relocation -2!
Comment 8 Steve Dodd 2018-06-14 06:24:29 UTC
I've hit this on Ubuntu 18.04 (xorg 1.19.6), modesetting driver. I have opened a bug over there in case someone on that side has time to investigate (https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1776447)

Interestingly, if I use VirtualGL as a true GLX proxy..

VGL_READBACK=sync LIBGL_ALWAYS_INDIRECT=1 VGL_DISPLAY=192.168.128.163:0 VGL_LOGO=1 vglrun +v /opt/VirtualGL/bin/glxspheres64

.. which I'm pretty sure it was never designed to do, things run successfully. So IGLX obviously isn't catastrophically broken ..


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.