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
europe.
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
node.
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!
best
Mathias
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
