primus

primus copied to clipboard

This error shows up for some, but not all applications, and I can't make it reproducible: When the application quits, this (or a similar) error is shown on the console:

X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 137 (DRI2) Minor opcode of failed request: 7 (DRI2GetBuffersWithFormat ) Resource id in failed request: 0x540005d Serial number of failed request: 3300 Current serial number in output stream: 3300

This does not happen when I use optirun instead of primusrun.

Unfortunately, I still don't know a good way to get notification of window destruction in D::work (and then there's also the need to avoid the race condition between checking the window status and calling glXSwapBuffers). What's worse, there's a variant of the above problem when D::work gets locked inside of glDrawBuffers, causing a deadlock in R::work reinit path.

I've committed an implementation of synchronous readback-display in sync-display branch (commit b64e11a8c01). It should not have this problem at the cost of major setback at performance (no parallel work).

Hi,

I've committed an implementation of synchronous readback-display in sync-display branch (commit b64e11a8c01). It should not have this problem at the cost of major setback at performance (no parallel work). So far I did not see X errors when using this branch. However, glxgears hangs when quitting...

Kind regards, Ralf

The above commits add sync mode to the master branch, so the errors on exit can be worked around with PRIMUS_SYNC=1 (or =2) at the cost of performance; synced modes also help under compositing WMs. Keeping this issue open as the real fix for errors on closing is needed, and the root cause of erratic behavior under compositing is not known.

The workaround seems to work, at least for Uru (where the X error occured almost all the time).

Reproduced the problem by alt-tabbing in/out of Anomaly: Warzone Earth by @msva's suggestion, researched this issue again and had an enlightening conversation in #dri-devel today. Basically, calling glXSwapBuffers on a destroyed drawable is not a horrible deed, and primus can go on if it arranges for that "error" to be non-fatal. That can be accomplished in a rather dirty way via changing the Xlib error handler (patch above, in glxswap-noerr-xlib branch), or in a more clean, but more involved way of rewriting all ddpy-side GLX chat via libxcb (but it won't work if ddpy side uses nvidia drivers :( ).