Re: [Mesa-dev] [RFC 00/10] Let us welcome EGLDevice
Hi Emil, On Tuesday, 4 September 2018 22:16:18 CEST Emil Velikov wrote: > Aaand it out, yet I forgot to CC you :-\ Never mind. I have seen that but did not find the time so far to test and review. But that's on my list. best Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 00/10] Let us welcome EGLDevice
On 4 September 2018 at 16:21, Mathias Fröhlich wrote: > Hi Emil, > > On Tuesday, 4 September 2018 16:21:49 CEST you wrote: >> > 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. >> >> Ouch, I should have noticed the "rw" for "other" of your render node. >> Looking at a Arch, Debian, Fedora and Ubuntu box - they all use 0660 >> for both card and render nodes. >> Which would explain why your described use case was not working, here ;-) >> >> Out of curiosity: you change that locally or it's a distro choice - >> which distro is that? > > I have been tracking down to systemd's git at > https://github.com/systemd/systemd.git: > > commit 4e15a7343cb389e97f3eb4f49699161862d8b8b2 > Author: Tom Stellard > Date: Tue Oct 31 08:46:24 2017 -0700 > > udev-rules: Permission changes for /dev/dri/renderD* > > - Remove the uaccess tag from /dev/dri/renderD*. > - Change the owning group from video to render. > - Change default mode to 0666. > - Add an option to allow users to set the access mode for these devices at > compile time. > > ... which pretty much makes perfect sense to me given the idea of render > nodes. > ... did I mention that already? > :-) > > I run currently on fedora-28 which runs > systemd-udev-238-9.git0e0aa59.fc28.x86_64 > as rpm package. > I saw that package, but misread it somehow. My Arch box has 239, but seemingly I haven't restarted it since. >> That said, v2 opens the render node directly, so it should work on your end. >> Just double-checking the crash is gone and I'll send them out. > > Great!! > Aaand it out, yet I forgot to CC you :-\ The crash was due to using a software device. I'm still working on that (requires a ton of semi-orthogonal work) so please pick a DRM device in the meanwhile. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 00/10] Let us welcome EGLDevice
Hi Emil, On Tuesday, 4 September 2018 16:21:49 CEST you wrote: > > 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. > > Ouch, I should have noticed the "rw" for "other" of your render node. > Looking at a Arch, Debian, Fedora and Ubuntu box - they all use 0660 > for both card and render nodes. > Which would explain why your described use case was not working, here ;-) > > Out of curiosity: you change that locally or it's a distro choice - > which distro is that? I have been tracking down to systemd's git at https://github.com/systemd/systemd.git: commit 4e15a7343cb389e97f3eb4f49699161862d8b8b2 Author: Tom Stellard Date: Tue Oct 31 08:46:24 2017 -0700 udev-rules: Permission changes for /dev/dri/renderD* - Remove the uaccess tag from /dev/dri/renderD*. - Change the owning group from video to render. - Change default mode to 0666. - Add an option to allow users to set the access mode for these devices at compile time. ... which pretty much makes perfect sense to me given the idea of render nodes. ... did I mention that already? :-) I run currently on fedora-28 which runs systemd-udev-238-9.git0e0aa59.fc28.x86_64 as rpm package. > That said, v2 opens the render node directly, so it should work on your end. > Just double-checking the crash is gone and I'll send them out. Great!! best Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 00/10] Let us welcome EGLDevice
HI Mathias,
On 30 August 2018 at 15:11, Mathias Fröhlich wrote:
>> >
>> > 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.
>
Ouch, I should have noticed the "rw" for "other" of your render node.
Looking at a Arch, Debian, Fedora and Ubuntu box - they all use 0660
for both card and render nodes.
Which would explain why your described use case was not working, here ;-)
Out of curiosity: you change that locally or it's a distro choice -
which distro is that?
That said, v2 opens the render node directly, so it should work on your end.
Just double-checking the crash is gone and I'll send them out.
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 00/10] Let us welcome EGLDevice
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
Re: [Mesa-dev] [RFC 00/10] Let us welcome EGLDevice
On 30 August 2018 at 10:54, Mathias Fröhlich wrote:
> On Tuesday, 28 August 2018 16:22:33 CEST Emil Velikov wrote:
>> > From a higher point of view the approach looks good.
>> >
>> > To sum up, you basically associate an _EGLDevice with each _EGLDisplay
>> > where the _EGLDevice only contains the meta information where to
>> > find the device and the _EGLDisplay later contains open file descriptors
>> > to work with ...
>>
>> It's the other way around - I associate each EGLDIsplay with a given
>> EGLDevice. The EGL_EXT_device_enumeration spec removed that (imho) bogus
>> relation:
>>
>> "Because the EGLDeviceEXT is a property of , any use of an
>> associated EGLDeviceEXT after has been terminated gives
>> undefined results. Querying an EGL_DEVICE_EXT from after a
>> call to eglTerminate() (and subsequent re-initialization) may
>> return a different value."
>
> Ok, wording difference. The _EGLDisplay has a member that points to an
> _EGLDevice. So each display has a device.
> But the list of _EGLDevices exists independent of the list of _EGLDisplays.
> Sounds plausible to me.
>
Precisely.
>> > Nevertheless, running the tests and proof of concept programs that I used
>> > back in the day brought up some questions and one crash.
>> >
>> > At first the Crash: The attached eglcontext-pbuffer.c which goes the
>> > pbuffer approach instead of going surfaceless just dumps core in pbuffer
>> > creation using the patch series. I believe that it is legal what the
>> > program does, but may be you want to double check that too.
>>
>> Off the top of my head, I think that's due to eglCreatePbufferSurface
>> instead of eglCreatePlatformPbufferSurfaceEXT.
>> I think we could wire that legacy API up, although the whole thing is
>> _really_ fiddly.
>>
>> See my piglit patch 85e3b32b3260184853ec20b938574c26a0f39dd8 for some
>> details.
>
> Can you explain that in more detail?
>
> Don't we have a initialized _EGLDisplay in our hands that does not require any
> further 'guessing of the underlying platform'.
>
Correct. We had a number of bugs (one of which breaking MT apps) that
makes me cautious.
> May be I am missing the latest development in this area, but I could not find
> any pointer to eglCreatePlatformPbufferSurfaceEXT in the wild. May be you can
> help out here?
>
You're correct - there isn't one. I should have checked the spec
because speaking.
> Anyhow, IMO it must not crash with a null pointer dereference even with the
> first patch series.
>
Agreed - will need to take a closer look why things crash, while the
piglit test works.
Might even add a piglit subtest.
>> > 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?
>
>> > For patch #7, can you explain why dri already provides the right format?
>> > It's probably correct, but I am missing some bits of that context creation
>> > big picture to give a review.
>>
>> The format used when to create a surface is passed to the driver,
>> which then calls back the loader with the exact same one.
>> Admittedly there's a ton of conversion back and forth (within the
>> driver) so it's not always clear.
>>
>> Pretty much every other platform respects the provided format, hence
>> my cleanup patches ;-)
>> That said, I'm perfectly fine with pulling those patches (and updating
>> platform_device.c) if it will make things easier.
>
> Thanks for that explanation.
> I see, it is the getBuffers call that routes that back into the loader.
> This is to align with the behavior of loader_dri3_
Re: [Mesa-dev] [RFC 00/10] Let us welcome EGLDevice
On Tuesday, 28 August 2018 16:22:33 CEST Emil Velikov wrote:
> > From a higher point of view the approach looks good.
> >
> > To sum up, you basically associate an _EGLDevice with each _EGLDisplay
> > where the _EGLDevice only contains the meta information where to
> > find the device and the _EGLDisplay later contains open file descriptors
> > to work with ...
>
> It's the other way around - I associate each EGLDIsplay with a given
> EGLDevice. The EGL_EXT_device_enumeration spec removed that (imho) bogus
> relation:
>
> "Because the EGLDeviceEXT is a property of , any use of an
> associated EGLDeviceEXT after has been terminated gives
> undefined results. Querying an EGL_DEVICE_EXT from after a
> call to eglTerminate() (and subsequent re-initialization) may
> return a different value."
Ok, wording difference. The _EGLDisplay has a member that points to an
_EGLDevice. So each display has a device.
But the list of _EGLDevices exists independent of the list of _EGLDisplays.
Sounds plausible to me.
> > Nevertheless, running the tests and proof of concept programs that I used
> > back in the day brought up some questions and one crash.
> >
> > At first the Crash: The attached eglcontext-pbuffer.c which goes the
> > pbuffer approach instead of going surfaceless just dumps core in pbuffer
> > creation using the patch series. I believe that it is legal what the
> > program does, but may be you want to double check that too.
>
> Off the top of my head, I think that's due to eglCreatePbufferSurface
> instead of eglCreatePlatformPbufferSurfaceEXT.
> I think we could wire that legacy API up, although the whole thing is
> _really_ fiddly.
>
> See my piglit patch 85e3b32b3260184853ec20b938574c26a0f39dd8 for some
> details.
Can you explain that in more detail?
Don't we have a initialized _EGLDisplay in our hands that does not require any
further 'guessing of the underlying platform'.
May be I am missing the latest development in this area, but I could not find
any pointer to eglCreatePlatformPbufferSurfaceEXT in the wild. May be you can
help out here?
Anyhow, IMO it must not crash with a null pointer dereference even with the
first patch series.
> > 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.
> > For patch #7, can you explain why dri already provides the right format?
> > It's probably correct, but I am missing some bits of that context creation
> > big picture to give a review.
>
> The format used when to create a surface is passed to the driver,
> which then calls back the loader with the exact same one.
> Admittedly there's a ton of conversion back and forth (within the
> driver) so it's not always clear.
>
> Pretty much every other platform respects the provided format, hence
> my cleanup patches ;-)
> That said, I'm perfectly fine with pulling those patches (and updating
> platform_device.c) if it will make things easier.
Thanks for that explanation.
I see, it is the getBuffers call that routes that back into the loader.
This is to align with the behavior of loader_dri3_get_buffers.
I am quite sure there are others here that can way better judge about possible
sideeffects of such changes. The change sounds plausible to me and if this
would be the only thing that holds back EGLDevices I can give my name for
that...
> > And finally, in patch #2 you mention that you want to avoid larger patches
> > and the announced extensions are not yet working as expected.
> > May be you can announce the extensions in a separate patch that follows
> > all the implementation patches? That probably helps people that want to
> > bisect something using piglit.
>
> It's actually patch 1/10 which "enables" the extensions.
Yes, may be put that hunk into a patch 3.5/10.
Then th
Re: [Mesa-dev] [RFC 00/10] Let us welcome EGLDevice
Thanks Mathias, On 28 August 2018 at 08:31, Mathias Fröhlich wrote: > Hi Emil, > > On Friday, 3 August 2018 14:44:16 CEST Emil Velikov wrote: >> Hi all, >> >> This series implements the following extensions: >> - EGL_EXT_device_base >> - EGL_MESA_device_software >> - EGL_EXT_device_drm >> - EGL_platform_device >> >> As you know the APIs are used to enumerate, select and use EGLDevices. >> The second extension (proposed by Ajax) defines a 'software' device, >> alongside the existing DRM ones. >> >> While there are many usecases for this work, my primary interest is >> allowing device selection, wrt testing. To achieve the goal, we would >> need to finalise EGL_EXT_explicit_device (also proposed by Ajax). >> >> Piglit patches will be sent out shortly. >> >> Any feedback is greatly appreciated. > > From a higher point of view the approach looks good. > > To sum up, you basically associate an _EGLDevice with each _EGLDisplay > where the _EGLDevice only contains the meta information where to > find the device and the _EGLDisplay later contains open file descriptors > to work with ... > It's the other way around - I associate each EGLDIsplay with a given EGLDevice. The EGL_EXT_device_enumeration spec removed that (imho) bogus relation: "Because the EGLDeviceEXT is a property of , any use of an associated EGLDeviceEXT after has been terminated gives undefined results. Querying an EGL_DEVICE_EXT from after a call to eglTerminate() (and subsequent re-initialization) may return a different value." > Nevertheless, running the tests and proof of concept programs that I used > back in the day brought up some questions and one crash. > > At first the Crash: The attached eglcontext-pbuffer.c which goes the pbuffer > approach > instead of going surfaceless just dumps core in pbuffer creation using > the patch series. I believe that it is legal what the program does, but may > be you want to double check that too. > Off the top of my head, I think that's due to eglCreatePbufferSurface instead of eglCreatePlatformPbufferSurfaceEXT. I think we could wire that legacy API up, although the whole thing is _really_ fiddly. See my piglit patch 85e3b32b3260184853ec20b938574c26a0f39dd8 for some details. > 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? > For patch #7, can you explain why dri already provides the right format? > It's probably correct, but I am missing some bits of that context creation > big picture to give a review. > The format used when to create a surface is passed to the driver, which then calls back the loader with the exact same one. Admittedly there's a ton of conversion back and forth (within the driver) so it's not always clear. Pretty much every other platform respects the provided format, hence my cleanup patches ;-) That said, I'm perfectly fine with pulling those patches (and updating platform_device.c) if it will make things easier. > And finally, in patch #2 you mention that you want to avoid larger patches > and the announced extensions are not yet working as expected. > May be you can announce the extensions in a separate patch that follows > all the implementation patches? That probably helps people that want to > bisect something using piglit. > It's actually patch 1/10 which "enables" the extensions. You're right though - we could merge the 1/10 boilerplate with 2/10 and enable the extensions once the SW _and_ DRM extensions have landed. Might even a) split the helpers from 3/10 into a prep patch and b) add the DRM _eglFindDevice instances of 3/10 into the DRM patch - 4/10. Another thing that comes to mind is ... minimise the first device is always SW assumption. That would involve adding a couple of _eglDeviceSupports(dev, _EGL_DEVICE_DRM) calls. It should make things less magical and clearer for the next EGL device extension. FTR swrast with platform_device is still WIP - I've been working fixing up swrast recently. It requires a ton of refactoring and fixes ;-) > thanks for approaching this topic! > Thank you for helping out with review and questions. I'll try to find time and respin the series tomorrow. Cheers Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 00/10] Let us welcome EGLDevice
Hi Emil,
On Friday, 3 August 2018 14:44:16 CEST Emil Velikov wrote:
> Hi all,
>
> This series implements the following extensions:
> - EGL_EXT_device_base
> - EGL_MESA_device_software
> - EGL_EXT_device_drm
> - EGL_platform_device
>
> As you know the APIs are used to enumerate, select and use EGLDevices.
> The second extension (proposed by Ajax) defines a 'software' device,
> alongside the existing DRM ones.
>
> While there are many usecases for this work, my primary interest is
> allowing device selection, wrt testing. To achieve the goal, we would
> need to finalise EGL_EXT_explicit_device (also proposed by Ajax).
>
> Piglit patches will be sent out shortly.
>
> Any feedback is greatly appreciated.
>From a higher point of view the approach looks good.
To sum up, you basically associate an _EGLDevice with each _EGLDisplay
where the _EGLDevice only contains the meta information where to
find the device and the _EGLDisplay later contains open file descriptors
to work with ...
Nevertheless, running the tests and proof of concept programs that I used
back in the day brought up some questions and one crash.
At first the Crash: The attached eglcontext-pbuffer.c which goes the pbuffer
approach
instead of going surfaceless just dumps core in pbuffer creation using
the patch series. I believe that it is legal what the program does, but may
be you want to double check that too.
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?
For patch #7, can you explain why dri already provides the right format?
It's probably correct, but I am missing some bits of that context creation
big picture to give a review.
And finally, in patch #2 you mention that you want to avoid larger patches
and the announced extensions are not yet working as expected.
May be you can announce the extensions in a separate patch that follows
all the implementation patches? That probably helps people that want to
bisect something using piglit.
thanks for approaching this topic!
best
Mathias
>
> Thanks
> Emil
>
> Emil Velikov (9):
> egl: add simple EGL_EXT_device_base implementation
> egl: add EGL_MESA_device_software support
> egl: add EGL_EXT_device_drm support
> meson: egl: group dri2 bits separately from haiku
> egl/surfaceless: inline surfaceless_alloc_image()
> egl/surfaceless: honour the format passed to getBuffers
> egl/surfaceless: remove no longer used dri2_egl_surface::visual
> egl: add optional plat_opt to _eglFindDisplay()
> egl: add EGL_platform_device support
>
> Jonny Lamb (1):
> egl: add initial boilerplate for EGL_EXT_device_base
>
> src/egl/Makefile.am | 3 +
> src/egl/Makefile.sources| 2 +
> src/egl/drivers/dri2/egl_dri2.c | 3 +
> src/egl/drivers/dri2/egl_dri2.h | 13 +-
> src/egl/drivers/dri2/platform_android.c | 9 +
> src/egl/drivers/dri2/platform_device.c | 380
> src/egl/drivers/dri2/platform_drm.c | 9 +
> src/egl/drivers/dri2/platform_surfaceless.c | 37 +-
> src/egl/drivers/dri2/platform_wayland.c | 18 +
> src/egl/drivers/dri2/platform_x11.c | 27 ++
> src/egl/drivers/haiku/egl_haiku.cpp | 8 +
> src/egl/main/eglapi.c | 79 +++-
> src/egl/main/egldevice.c| 306
> src/egl/main/egldevice.h| 83 +
> src/egl/main/egldisplay.c | 119 +-
> src/egl/main/egldisplay.h | 14 +-
> src/egl/main/eglentrypoint.h| 4 +
> src/egl/main/eglglobals.c | 10 +-
> src/egl/main/eglglobals.h | 2 +
> src/egl/main/egltypedefs.h | 2 +
> src/egl/meson.build | 68 ++--
> 21 files changed, 1120 insertions(+), 76 deletions(-)
> create mode 100644 src/egl/drivers/dri2/platform_device.c
> create mode 100644 src/egl/main/egldevice.c
> create mode 100644 src/egl/main/egldevice.h
>
>
// For RTLD_DEFAULT
#define _GNU_SOURCE
#include
#include
#include
#include
// open/close for gbm
#include
#include
#include
#include
#include
#include
#include
#include
static int
check_extension(EGLDisplay dpy, const char* name)
{
const char *extensions = eglQueryString(dpy, EGL_EXTENSIONS);
// It does not hurt to check this always, but by spec only
// required if we look for client extensions
if (/*dpy == EGL_NO_DISPLAY && */ !extensions)
return 0;
// Not great as we match
[Mesa-dev] [RFC 00/10] Let us welcome EGLDevice
Hi all, This series implements the following extensions: - EGL_EXT_device_base - EGL_MESA_device_software - EGL_EXT_device_drm - EGL_platform_device As you know the APIs are used to enumerate, select and use EGLDevices. The second extension (proposed by Ajax) defines a 'software' device, alongside the existing DRM ones. While there are many usecases for this work, my primary interest is allowing device selection, wrt testing. To achieve the goal, we would need to finalise EGL_EXT_explicit_device (also proposed by Ajax). Piglit patches will be sent out shortly. Any feedback is greatly appreciated. Thanks Emil Emil Velikov (9): egl: add simple EGL_EXT_device_base implementation egl: add EGL_MESA_device_software support egl: add EGL_EXT_device_drm support meson: egl: group dri2 bits separately from haiku egl/surfaceless: inline surfaceless_alloc_image() egl/surfaceless: honour the format passed to getBuffers egl/surfaceless: remove no longer used dri2_egl_surface::visual egl: add optional plat_opt to _eglFindDisplay() egl: add EGL_platform_device support Jonny Lamb (1): egl: add initial boilerplate for EGL_EXT_device_base src/egl/Makefile.am | 3 + src/egl/Makefile.sources| 2 + src/egl/drivers/dri2/egl_dri2.c | 3 + src/egl/drivers/dri2/egl_dri2.h | 13 +- src/egl/drivers/dri2/platform_android.c | 9 + src/egl/drivers/dri2/platform_device.c | 380 src/egl/drivers/dri2/platform_drm.c | 9 + src/egl/drivers/dri2/platform_surfaceless.c | 37 +- src/egl/drivers/dri2/platform_wayland.c | 18 + src/egl/drivers/dri2/platform_x11.c | 27 ++ src/egl/drivers/haiku/egl_haiku.cpp | 8 + src/egl/main/eglapi.c | 79 +++- src/egl/main/egldevice.c| 306 src/egl/main/egldevice.h| 83 + src/egl/main/egldisplay.c | 119 +- src/egl/main/egldisplay.h | 14 +- src/egl/main/eglentrypoint.h| 4 + src/egl/main/eglglobals.c | 10 +- src/egl/main/eglglobals.h | 2 + src/egl/main/egltypedefs.h | 2 + src/egl/meson.build | 68 ++-- 21 files changed, 1120 insertions(+), 76 deletions(-) create mode 100644 src/egl/drivers/dri2/platform_device.c create mode 100644 src/egl/main/egldevice.c create mode 100644 src/egl/main/egldevice.h -- 2.18.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
