[Mesa-dev] [RFC 00/10] Let us welcome EGLDevice

Mathias Fröhlich Mathias.Froehlich at gmx.net
Thu Aug 30 14:11:11 UTC 2018

Hi Emil,

> Correct. We had a number of bugs (one of which breaking MT apps) that
> makes me cautious.
Working with environment variables basically is often asking for problems. The 
thread race condition ones being the most prominent.
To overwrite something - especially for debugging - its ok to use the 
environment IMO. But there should always be a non environment variable API for 
normal use.

> Agreed - will need to take a closer look why things crash, while the
> piglit test works.
> Might even add a piglit subtest.

That would be great.

Once the development machine is restored form backup, I should have one more 
piglit test that I wrote once for that basic set of extensions. Mostly 
overlapping with what you committed lately, but may be still useful.

> >> > Then if I use the patch series on an account that has no DISPLAY set
> >> > and
> >> > no
> >> > 'display server' running, eglInitialize fails in device_probe_device
> >> > due
> >> > to at first opening the '.../card0' device and bailing out when this
> >> > does
> >> > not work. Means the current patch series goes via opening the primary
> >> > node which shall not be accessible by everyone and from that derives
> >> > the
> >> > rendernode device which is finally used for _EGLDisplay initialization.
> >> > Can we alternatively go directly to the rendernode in some way?
> >> 
> >> I think we could. Can you elaborate a bit more or provide an example
> >> on the topic though.
> >> I'm quite curious what's happening here - is there no card0 node,
> >> open() fails, other?
> > 
> > It's just the file permissions:
> > 
> > $ ls -l /dev/dri/{card*,render*}
> > crw-rw----+ 1 root video  226,   0 Aug 30 08:28 /dev/dri/card0
> > crw-rw-rw-  1 root render 226, 128 Aug 30 08:28 /dev/dri/renderD128
> > 
> > which is pretty much what I expect from the basic idea of render nodes.
> > As long as you are the one logged into the console you can access card0
> > via an dynamically added acl. But if you are not logged into the console,
> > which is at least one of the major driving use cases of the device
> > enumeration extension, the current implementation fails with opening
> > card0.
> IIRC when someone gets logged in systemd/logind/others sets up the ACL
> -  both ownership and permissions.
> So an open(/dev/dri/card0) will be fine - be that from tty or the DE
> terminal emulator.
> Can you share a brief how-to reproduce?

ssh different-machine.somewhere

Then you will see that you are not added to the card0 acl as you are not 
logged to any console.

Basically this set of extensions should give anyone who has access to the cpu 
to compute something from his data also access to the gpu to compute/render 
some pictures from his data.

The practical use case is really: You sit in Central Europe with your CAD 
model and you prepared that for some simulation. That simulation will later 
run on a compute cluster located anywhere but central europe. May be think of 
a country where cooling is easier and electricity is cheaper. You copy your 
prepared model to one cluster file system there and start to produce terabytes 
of data on that cluser filesystem. Either your postprocessing runs then later 
on on some machine with a GPU or your simulation program - mostly using MPI - 
transfers data for postprocessing to some GPU nodes inside the MPI program on 
the cluster and generates some images that you will take a look afterwards. 
Usually the images are some megabytes that you can copy back to central 
Also please don't nail that argument down to ssh. You can find very creative 
solutions in high performance computing on different machines. Some of them 
still use telnet or rsh to spawn their sub processes. Some queuing systems 
have custom daemons and protocols to start compute processes onto some compute 

Long story short, you just cannot assume that you have access to card*.

> Ouch. Hope you have backups for your important bits.
Yes, I have. I will loose hand full of mails from until the previous evening, 
but appart from that, nothing else. Thanks for asking!



More information about the mesa-dev mailing list