Bug 93286 - Weird behaviour sharing textures between contexts (glGetTexImage works, but painting crashes) unless sharing display values
Summary: Weird behaviour sharing textures between contexts (glGetTexImage works, but p...
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915 (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ian Romanick
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-07 19:59 UTC by Emilio Cobos Álvarez
Modified: 2019-09-18 19:39 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Test case (9.37 KB, text/plain)
2015-12-07 19:59 UTC, Emilio Cobos Álvarez
Details
glxinfo output (23.54 KB, text/plain)
2015-12-07 20:00 UTC, Emilio Cobos Álvarez
Details
More reduced test case (7.55 KB, text/x-c++src)
2016-08-19 06:56 UTC, Emilio Cobos Álvarez
Details

Description Emilio Cobos Álvarez 2015-12-07 19:59:58 UTC
Created attachment 120394 [details]
Test case

I initially discovered this bug trying to share textures from different threads, but it also fails in single-threaded mode.

A texture created using a shared context, 

Trying to paint a texture created from another thread (using a shared context) generates garbage unless that context has been created using the same display value, and sooner or later ends up crashing with:

```
intel_do_flush_locked failed: No such file or directory
```

I attach a test case that crashes on resize for me (when using the shared texture). I used glut for convenience in the test-case, if you want me to update it to use just X/GLX, please tell me.

To compile the test-case I used:

```
g++ test.cpp -std=c++11 -Wall -pedantic -lX11 -lGL -lglut -pthread -o test
```

The test-case just creates a 1x1 blue texture in the main thread, and a 1x1 red texture in another thread, using a shared context, and then tries to paint the second one using a simple GL program from the first one, once the shared context has been unbound.

The test-case as-is produces a crash on resize (the first paint grabs the first texture), but if comments in lines 60 and 61 are toggled (if the shared context uses the same display value as the "main" one), it produces the expected output.

The weird thing is that `glGetTexLevelParameteriv` and `glGetTexImage` work as expected, even when not using the same display value.

I use an integrated Intel HD4600 card.

Another person tested it with propietary nvidia drivers and the test-case worked as expected.
Comment 1 Emilio Cobos Álvarez 2015-12-07 20:00:39 UTC
Created attachment 120395 [details]
glxinfo output
Comment 2 Emilio Cobos Álvarez 2016-08-19 06:56:12 UTC
Created attachment 125904 [details]
More reduced test case

Hey, sorry for the super-bad testcase I attached a year ago, it was lame (I was arguably inexperienced reporting bugs).

There goes the test-case more cleaned up, without mulithreading or things like that.

The bug goes away if I change the line:

Display* dpy = XOpenDisplay(NULL);

for

Display* dpy = main_display;

It works fine with LIBGL_ALWAYS_SOFTWARE=1, and also with gallium and libllvmpipe.
Comment 3 GitLab Migration User 2019-09-18 19:39:08 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/757.


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.