Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
On Mon, May 6, 2019 at 11:19 AM Emil Velikov wrote: > On Sat, 4 May 2019 at 04:18, Marek Olšák wrote: > > > > On Fri, May 3, 2019 at 1:58 AM Mathias Fröhlich < > mathias.froehl...@gmx.net> wrote: > >> > >> Good Morning, > >> > >> On Wednesday, 1 May 2019 21:43:08 CEST Marek Olšák wrote: > >> > BTW, swrast doesn't have to exist on the system. It's not uncommon > for me > >> > to have no swrast on my development system. > >> > >> Ok. I see. I use swrast regularly to test changes with different > backend drivers. > >> Also especially classic swrast as something that is close to the good > old swtnl > >> drivers - to catch bad interactions with those. > >> > >> Anyhow, with a very old swrast I think you will get test failures. > >> But else if the system swrast is found in the hopefully not so distant > future > >> the tests should even pass - well depends on what Emil now does to get a > >> better overall swrast behavior. > >> On a production system with a full set of driver packages I do expect to > >> find swrast, right? At least on a workstation grade linux distribution. > >> > >> I start to see the actual problem for AMD there. > >> Not your test system at home, but the pro driver that needs to ship > >> and QA swrast then. > >> > >> Anyhow, I do not actually understand the way how we walk all > >> installed egl driver implementations - including closed drivers - > finally > >> and present all those devices. In a perfect world *for the customer* > >> I could enumerate all devices - including oss i965 and the closed nvidia > >> bumblebee device - on my laptop for example. > >> > >> Means - if that works fine AMD could hook into that mechanism and > >> provide further devices. Well - in the long term. > > > > > > We include libGL and libEGL along with radeonsi in our binary driver > installer. We probably don't include swrast, but I'm not 100% sure. > > > The series I just sent out covers everything but the "don't expose the > software device". It does include a hack which can be toggled to > achieve that though ;-) > > My line of thinking is as follows: > > Preamble: > A software device is only listed when the user requests the full > device list via QueryDevices and even then, it's the last one in the > list. > Thus it's close to impossible to get it "by mistake". > > Case A - average Joe: > Getting Mesa from their distribution - swrast is build and shipped. > > Case B - tailored solution like AMDGPU-PRO, Yocto builders or others: > People doing the platform integration know if swrast will be > built/available. If listing the software device is not something > they're interested, the trivial hack can be applied locally. > > This seems like a perfectly good middle-ground, don't you agree? > Yes, it's OK. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
On Sat, 4 May 2019 at 04:18, Marek Olšák wrote: > > On Fri, May 3, 2019 at 1:58 AM Mathias Fröhlich > wrote: >> >> Good Morning, >> >> On Wednesday, 1 May 2019 21:43:08 CEST Marek Olšák wrote: >> > BTW, swrast doesn't have to exist on the system. It's not uncommon for me >> > to have no swrast on my development system. >> >> Ok. I see. I use swrast regularly to test changes with different backend >> drivers. >> Also especially classic swrast as something that is close to the good old >> swtnl >> drivers - to catch bad interactions with those. >> >> Anyhow, with a very old swrast I think you will get test failures. >> But else if the system swrast is found in the hopefully not so distant future >> the tests should even pass - well depends on what Emil now does to get a >> better overall swrast behavior. >> On a production system with a full set of driver packages I do expect to >> find swrast, right? At least on a workstation grade linux distribution. >> >> I start to see the actual problem for AMD there. >> Not your test system at home, but the pro driver that needs to ship >> and QA swrast then. >> >> Anyhow, I do not actually understand the way how we walk all >> installed egl driver implementations - including closed drivers - finally >> and present all those devices. In a perfect world *for the customer* >> I could enumerate all devices - including oss i965 and the closed nvidia >> bumblebee device - on my laptop for example. >> >> Means - if that works fine AMD could hook into that mechanism and >> provide further devices. Well - in the long term. > > > We include libGL and libEGL along with radeonsi in our binary driver > installer. We probably don't include swrast, but I'm not 100% sure. > The series I just sent out covers everything but the "don't expose the software device". It does include a hack which can be toggled to achieve that though ;-) My line of thinking is as follows: Preamble: A software device is only listed when the user requests the full device list via QueryDevices and even then, it's the last one in the list. Thus it's close to impossible to get it "by mistake". Case A - average Joe: Getting Mesa from their distribution - swrast is build and shipped. Case B - tailored solution like AMDGPU-PRO, Yocto builders or others: People doing the platform integration know if swrast will be built/available. If listing the software device is not something they're interested, the trivial hack can be applied locally. This seems like a perfectly good middle-ground, don't you agree? HTH Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
On Fri, May 3, 2019 at 1:58 AM Mathias Fröhlich wrote: > Good Morning, > > On Wednesday, 1 May 2019 21:43:08 CEST Marek Olšák wrote: > > BTW, swrast doesn't have to exist on the system. It's not uncommon for me > > to have no swrast on my development system. > > Ok. I see. I use swrast regularly to test changes with different backend > drivers. > Also especially classic swrast as something that is close to the good old > swtnl > drivers - to catch bad interactions with those. > > Anyhow, with a very old swrast I think you will get test failures. > But else if the system swrast is found in the hopefully not so distant > future > the tests should even pass - well depends on what Emil now does to get a > better overall swrast behavior. > On a production system with a full set of driver packages I do expect to > find swrast, right? At least on a workstation grade linux distribution. > > I start to see the actual problem for AMD there. > Not your test system at home, but the pro driver that needs to ship > and QA swrast then. > > Anyhow, I do not actually understand the way how we walk all > installed egl driver implementations - including closed drivers - finally > and present all those devices. In a perfect world *for the customer* > I could enumerate all devices - including oss i965 and the closed nvidia > bumblebee device - on my laptop for example. > > Means - if that works fine AMD could hook into that mechanism and > provide further devices. Well - in the long term. > We include libGL and libEGL along with radeonsi in our binary driver installer. We probably don't include swrast, but I'm not 100% sure. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
Good Morning, On Wednesday, 1 May 2019 21:43:08 CEST Marek Olšák wrote: > BTW, swrast doesn't have to exist on the system. It's not uncommon for me > to have no swrast on my development system. Ok. I see. I use swrast regularly to test changes with different backend drivers. Also especially classic swrast as something that is close to the good old swtnl drivers - to catch bad interactions with those. Anyhow, with a very old swrast I think you will get test failures. But else if the system swrast is found in the hopefully not so distant future the tests should even pass - well depends on what Emil now does to get a better overall swrast behavior. On a production system with a full set of driver packages I do expect to find swrast, right? At least on a workstation grade linux distribution. I start to see the actual problem for AMD there. Not your test system at home, but the pro driver that needs to ship and QA swrast then. Anyhow, I do not actually understand the way how we walk all installed egl driver implementations - including closed drivers - finally and present all those devices. In a perfect world *for the customer* I could enumerate all devices - including oss i965 and the closed nvidia bumblebee device - on my laptop for example. Means - if that works fine AMD could hook into that mechanism and provide further devices. Well - in the long term. Thinking ... best Mathias > > Marek > > On Wed, May 1, 2019 at 4:30 AM Mathias Fröhlich > wrote: > > > Hi Marek, Emil, > > > > On Tuesday, 30 April 2019 15:36:08 CEST Emil Velikov wrote: > > > On Mon, 29 Apr 2019 at 22:50, Marek Olšák wrote: > > > > > > > > On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen > > wrote: > > > >> > > > >> On Sat, 27 Apr 2019 09:38:27 -0400 > > > >> Marek Olšák wrote: > > > >> > > > >> > Those are all valid reasons, but I don't wanna expose swrast for > > AMD's > > > >> > customers. > > > >> > > > >> Hi Marek, > > > >> > > > >> is you objection that you will never want to see any software renderer > > > >> in the list, or that you don't want to see a software renderer only as > > > >> long as it doesn't actually work? > > > >> > > > >> Why do you not "wanna expose swrast for AMD's customers"? > > > >> > > > >> Are you talking about swrast specifically or all the software > > renderers > > > >> in Mesa? > > > >> > > > >> I'm not an AMD customer if you mean someone paying for support rather > > > >> than just buying their hardware, so I cannot speak for them. However, > > I > > > >> would be very happy to have a software renderer available to be picked > > > >> the same way as any other hardware renderer, so that I can use it in > > > >> graphical test suites (a point from Anholt) testing also the EGL glue > > > >> in addition to the pixels produced. > > > >> > > > >> The thing will be run on boxes with AMD GPUs, and in those cases there > > > >> must be a way to *not* use the AMD GPU, and use the software renderer > > > >> instead when wanted. Not by environment variables or anything hacky > > > >> like that, but by deliberately choosing the software renderer in the > > > >> program. It will need an EGLSurface too. > > > >> > > > >> How would this be made to work in the future? > > > > > > > > > > > > A software renderer could be exposed by adding a new EGL function on > > top of EGL_EXT_device_base, for example: > > > > > > > > // EGL_MESA_device_software > > > > > > > > EGLBoolean eglQuerySoftwareDeviceMESA(EGLDeviceEXT *swdevice); > > > > > > > > > > > > You would get the swrast device from that function instead of > > eglQueryDevicesEXT. It clearly separates hw and sw devices but keeps > > everything else the same. > > > > > > > IMHO the current EGL_MESA_device_software approach is perfectly valid. > > > The Query API provides the devices and one can query their > > > capabilities/device extensions. > > > > I agree with that. Well to repeat myself. > > > > For me there is also a basic consistency argument behind. > > So, Marek, you propose that the swrast device should only show > > up when there is no other device. That means swrast qualifies in > > principle as a 'device'. > > But if there is an other 'device' then swrast is not a 'device' anymore? > > I can not quite understand that from the outside. > > Means if swrast qualifies as a device in one configuration if should also > > be a device in any other configuration. > > > > There is also a next problem. I can understand that AMD wants to avoid > > for a customer to grab the swrast device by accident and get worse > > performance. > > But where do you draw the line then? Do you want to block out a drm device > > that comes up as a administration console device in such a typical compute > > cluster when there is an AMD device available? I mean for the same reason, > > where you want to avoid an application to grab the matrox device on that > > board > > that is put there for some sort of framebuffer console? If does AMD then > > negotiate with > > the
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
BTW, swrast doesn't have to exist on the system. It's not uncommon for me to have no swrast on my development system. Marek On Wed, May 1, 2019 at 4:30 AM Mathias Fröhlich wrote: > Hi Marek, Emil, > > On Tuesday, 30 April 2019 15:36:08 CEST Emil Velikov wrote: > > On Mon, 29 Apr 2019 at 22:50, Marek Olšák wrote: > > > > > > On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen > wrote: > > >> > > >> On Sat, 27 Apr 2019 09:38:27 -0400 > > >> Marek Olšák wrote: > > >> > > >> > Those are all valid reasons, but I don't wanna expose swrast for > AMD's > > >> > customers. > > >> > > >> Hi Marek, > > >> > > >> is you objection that you will never want to see any software renderer > > >> in the list, or that you don't want to see a software renderer only as > > >> long as it doesn't actually work? > > >> > > >> Why do you not "wanna expose swrast for AMD's customers"? > > >> > > >> Are you talking about swrast specifically or all the software > renderers > > >> in Mesa? > > >> > > >> I'm not an AMD customer if you mean someone paying for support rather > > >> than just buying their hardware, so I cannot speak for them. However, > I > > >> would be very happy to have a software renderer available to be picked > > >> the same way as any other hardware renderer, so that I can use it in > > >> graphical test suites (a point from Anholt) testing also the EGL glue > > >> in addition to the pixels produced. > > >> > > >> The thing will be run on boxes with AMD GPUs, and in those cases there > > >> must be a way to *not* use the AMD GPU, and use the software renderer > > >> instead when wanted. Not by environment variables or anything hacky > > >> like that, but by deliberately choosing the software renderer in the > > >> program. It will need an EGLSurface too. > > >> > > >> How would this be made to work in the future? > > > > > > > > > A software renderer could be exposed by adding a new EGL function on > top of EGL_EXT_device_base, for example: > > > > > > // EGL_MESA_device_software > > > > > > EGLBoolean eglQuerySoftwareDeviceMESA(EGLDeviceEXT *swdevice); > > > > > > > > > You would get the swrast device from that function instead of > eglQueryDevicesEXT. It clearly separates hw and sw devices but keeps > everything else the same. > > > > > IMHO the current EGL_MESA_device_software approach is perfectly valid. > > The Query API provides the devices and one can query their > > capabilities/device extensions. > > I agree with that. Well to repeat myself. > > For me there is also a basic consistency argument behind. > So, Marek, you propose that the swrast device should only show > up when there is no other device. That means swrast qualifies in > principle as a 'device'. > But if there is an other 'device' then swrast is not a 'device' anymore? > I can not quite understand that from the outside. > Means if swrast qualifies as a device in one configuration if should also > be a device in any other configuration. > > There is also a next problem. I can understand that AMD wants to avoid > for a customer to grab the swrast device by accident and get worse > performance. > But where do you draw the line then? Do you want to block out a drm device > that comes up as a administration console device in such a typical compute > cluster when there is an AMD device available? I mean for the same reason, > where you want to avoid an application to grab the matrox device on that > board > that is put there for some sort of framebuffer console? If does AMD then > negotiate with > the Intel guys if their chip qualifies as 'device' in this sense? > Do you then maintain a list of 'hardware devices' that qualify for a 'real > device' then? > > As I said I can understand that the first device should be a GPU hardware > backed device > when possible to catch those simple example programs that only grab the > first device. > And I am still in favor of sorting this device list in a different way > than it is today. > > Looking at that, it's probably a bit more educative to have the swrast > device there in > any case. That makes the average developer making use of that api aware > that he has to > look a bit closer at the devices before blindly using the first one. This > awareness makes > the administrative console device case being handled in the using > application. That in turn > will probably lead to the final effect that I would like to see as a GPU > vendor, that is > applications grab a GPU backed device and users are happy with the > performance. > > As Emil mentions, you can find out if you grabed a swrast device or not. > There is the case that your device is DRM backed, or swrast, or nothing - > then its nvidia closed. > > > As far as I can see you have valid concerns: > > - HW devices should be the first/default > > - the SW device should work, if exposed > > - one may want to omit the SW one all together > > > > At the same time: > > - the device_base extension is explicit that at least one device must > > be present >
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
Hi Marek, Emil, On Tuesday, 30 April 2019 15:36:08 CEST Emil Velikov wrote: > On Mon, 29 Apr 2019 at 22:50, Marek Olšák wrote: > > > > On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen wrote: > >> > >> On Sat, 27 Apr 2019 09:38:27 -0400 > >> Marek Olšák wrote: > >> > >> > Those are all valid reasons, but I don't wanna expose swrast for AMD's > >> > customers. > >> > >> Hi Marek, > >> > >> is you objection that you will never want to see any software renderer > >> in the list, or that you don't want to see a software renderer only as > >> long as it doesn't actually work? > >> > >> Why do you not "wanna expose swrast for AMD's customers"? > >> > >> Are you talking about swrast specifically or all the software renderers > >> in Mesa? > >> > >> I'm not an AMD customer if you mean someone paying for support rather > >> than just buying their hardware, so I cannot speak for them. However, I > >> would be very happy to have a software renderer available to be picked > >> the same way as any other hardware renderer, so that I can use it in > >> graphical test suites (a point from Anholt) testing also the EGL glue > >> in addition to the pixels produced. > >> > >> The thing will be run on boxes with AMD GPUs, and in those cases there > >> must be a way to *not* use the AMD GPU, and use the software renderer > >> instead when wanted. Not by environment variables or anything hacky > >> like that, but by deliberately choosing the software renderer in the > >> program. It will need an EGLSurface too. > >> > >> How would this be made to work in the future? > > > > > > A software renderer could be exposed by adding a new EGL function on top of > > EGL_EXT_device_base, for example: > > > > // EGL_MESA_device_software > > > > EGLBoolean eglQuerySoftwareDeviceMESA(EGLDeviceEXT *swdevice); > > > > > > You would get the swrast device from that function instead of > > eglQueryDevicesEXT. It clearly separates hw and sw devices but keeps > > everything else the same. > > > IMHO the current EGL_MESA_device_software approach is perfectly valid. > The Query API provides the devices and one can query their > capabilities/device extensions. I agree with that. Well to repeat myself. For me there is also a basic consistency argument behind. So, Marek, you propose that the swrast device should only show up when there is no other device. That means swrast qualifies in principle as a 'device'. But if there is an other 'device' then swrast is not a 'device' anymore? I can not quite understand that from the outside. Means if swrast qualifies as a device in one configuration if should also be a device in any other configuration. There is also a next problem. I can understand that AMD wants to avoid for a customer to grab the swrast device by accident and get worse performance. But where do you draw the line then? Do you want to block out a drm device that comes up as a administration console device in such a typical compute cluster when there is an AMD device available? I mean for the same reason, where you want to avoid an application to grab the matrox device on that board that is put there for some sort of framebuffer console? If does AMD then negotiate with the Intel guys if their chip qualifies as 'device' in this sense? Do you then maintain a list of 'hardware devices' that qualify for a 'real device' then? As I said I can understand that the first device should be a GPU hardware backed device when possible to catch those simple example programs that only grab the first device. And I am still in favor of sorting this device list in a different way than it is today. Looking at that, it's probably a bit more educative to have the swrast device there in any case. That makes the average developer making use of that api aware that he has to look a bit closer at the devices before blindly using the first one. This awareness makes the administrative console device case being handled in the using application. That in turn will probably lead to the final effect that I would like to see as a GPU vendor, that is applications grab a GPU backed device and users are happy with the performance. As Emil mentions, you can find out if you grabed a swrast device or not. There is the case that your device is DRM backed, or swrast, or nothing - then its nvidia closed. > As far as I can see you have valid concerns: > - HW devices should be the first/default > - the SW device should work, if exposed > - one may want to omit the SW one all together > > At the same time: > - the device_base extension is explicit that at least one device must > be present > - manipulating the EGL client extension string, before we determine > the driver is a PITA > > How about: > - whip a quick (admittedly gross) hack that makes SW work > - flip the order so SW is always the last one in the list > - add a hack that disables SW all-together? I would vote for reordering the device list to have swrast in the last position. > > The first two
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
On Mon, 29 Apr 2019 at 22:50, Marek Olšák wrote: > > On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen wrote: >> >> On Sat, 27 Apr 2019 09:38:27 -0400 >> Marek Olšák wrote: >> >> > Those are all valid reasons, but I don't wanna expose swrast for AMD's >> > customers. >> >> Hi Marek, >> >> is you objection that you will never want to see any software renderer >> in the list, or that you don't want to see a software renderer only as >> long as it doesn't actually work? >> >> Why do you not "wanna expose swrast for AMD's customers"? >> >> Are you talking about swrast specifically or all the software renderers >> in Mesa? >> >> I'm not an AMD customer if you mean someone paying for support rather >> than just buying their hardware, so I cannot speak for them. However, I >> would be very happy to have a software renderer available to be picked >> the same way as any other hardware renderer, so that I can use it in >> graphical test suites (a point from Anholt) testing also the EGL glue >> in addition to the pixels produced. >> >> The thing will be run on boxes with AMD GPUs, and in those cases there >> must be a way to *not* use the AMD GPU, and use the software renderer >> instead when wanted. Not by environment variables or anything hacky >> like that, but by deliberately choosing the software renderer in the >> program. It will need an EGLSurface too. >> >> How would this be made to work in the future? > > > A software renderer could be exposed by adding a new EGL function on top of > EGL_EXT_device_base, for example: > > // EGL_MESA_device_software > > EGLBoolean eglQuerySoftwareDeviceMESA(EGLDeviceEXT *swdevice); > > > You would get the swrast device from that function instead of > eglQueryDevicesEXT. It clearly separates hw and sw devices but keeps > everything else the same. > IMHO the current EGL_MESA_device_software approach is perfectly valid. The Query API provides the devices and one can query their capabilities/device extensions. As far as I can see you have valid concerns: - HW devices should be the first/default - the SW device should work, if exposed - one may want to omit the SW one all together At the same time: - the device_base extension is explicit that at least one device must be present - manipulating the EGL client extension string, before we determine the driver is a PITA How about: - whip a quick (admittedly gross) hack that makes SW work - flip the order so SW is always the last one in the list - add a hack that disables SW all-together? The first two should be OK to upstream, although I'd suggest keeping the last one in AMDGPU-PRO. Reason being is that the pro packaging can enforce that radeonsi is always present. While we cannot do that for distributions :-\ /me starts working on the patches -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen wrote: > On Sat, 27 Apr 2019 09:38:27 -0400 > Marek Olšák wrote: > > > Those are all valid reasons, but I don't wanna expose swrast for AMD's > > customers. > > Hi Marek, > > is you objection that you will never want to see any software renderer > in the list, or that you don't want to see a software renderer only as > long as it doesn't actually work? > > Why do you not "wanna expose swrast for AMD's customers"? > > Are you talking about swrast specifically or all the software renderers > in Mesa? > > I'm not an AMD customer if you mean someone paying for support rather > than just buying their hardware, so I cannot speak for them. However, I > would be very happy to have a software renderer available to be picked > the same way as any other hardware renderer, so that I can use it in > graphical test suites (a point from Anholt) testing also the EGL glue > in addition to the pixels produced. > > The thing will be run on boxes with AMD GPUs, and in those cases there > must be a way to *not* use the AMD GPU, and use the software renderer > instead when wanted. Not by environment variables or anything hacky > like that, but by deliberately choosing the software renderer in the > program. It will need an EGLSurface too. > > How would this be made to work in the future? > A software renderer could be exposed by adding a new EGL function on top of EGL_EXT_device_base, for example: // EGL_MESA_device_software EGLBoolean eglQuerySoftwareDeviceMESA(EGLDeviceEXT *swdevice); You would get the swrast device from that function instead of eglQueryDevicesEXT. It clearly separates hw and sw devices but keeps everything else the same. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
On Sat, 27 Apr 2019 09:38:27 -0400 Marek Olšák wrote: > Those are all valid reasons, but I don't wanna expose swrast for AMD's > customers. Hi Marek, is you objection that you will never want to see any software renderer in the list, or that you don't want to see a software renderer only as long as it doesn't actually work? Why do you not "wanna expose swrast for AMD's customers"? Are you talking about swrast specifically or all the software renderers in Mesa? I'm not an AMD customer if you mean someone paying for support rather than just buying their hardware, so I cannot speak for them. However, I would be very happy to have a software renderer available to be picked the same way as any other hardware renderer, so that I can use it in graphical test suites (a point from Anholt) testing also the EGL glue in addition to the pixels produced. The thing will be run on boxes with AMD GPUs, and in those cases there must be a way to *not* use the AMD GPU, and use the software renderer instead when wanted. Not by environment variables or anything hacky like that, but by deliberately choosing the software renderer in the program. It will need an EGLSurface too. How would this be made to work in the future? Thanks, pq > > Marek > > On Sat, Apr 27, 2019, 5:45 AM Mathias Fröhlich > wrote: > > > Hi Marek, > > > > On Wednesday, 24 April 2019 02:01:42 CEST Marek Olšák wrote: > > > Adam, did you notice my original suggestion "If there is at least 1 drm > > > device, swrast won't be in the list."? which means swrast would be in the > > > list for your "dumb" GPUs. > > > > Imagine a box with a low end drm capable hardware chip like you find > > sometimes > > in server type boxes (intel/matrox...). Otherwise the box is equipped with > > lots of cpu > > power. This is something that you will find a lot in that major > > engineering application > > environment. Your application will be glad to find the swrast renderer > > that is finally > > more capable than the 'GPU' mostly there to drive an administration > > console. > > You do not want to lock a swrast 'device' (or however you want to call it) > > out by > > a may be less capable 'console GPU'. > > > > Beside that having a second type of 'normalized renderer' like Eric was > > telling > > about is an other one. > > > > As well as sometimes it may make sense to utilize the GPU > > with one set of work and a second GPU with an other set of work in > > parallel. > > When you only find a single gpu device in one box, you may be glad to find > > a swrast device that you can make use of in parallel with the gpu without > > the need > > to put up different code paths in your application. > > > > May be I can come up with other cases, but thats the 5 minutes for now ... > > > > best > > > > Mathias > > > > > > pgpYCtED5brQZ.pgp Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
Those are all valid reasons, but I don't wanna expose swrast for AMD's customers. Marek On Sat, Apr 27, 2019, 5:45 AM Mathias Fröhlich wrote: > Hi Marek, > > On Wednesday, 24 April 2019 02:01:42 CEST Marek Olšák wrote: > > Adam, did you notice my original suggestion "If there is at least 1 drm > > device, swrast won't be in the list."? which means swrast would be in the > > list for your "dumb" GPUs. > > Imagine a box with a low end drm capable hardware chip like you find > sometimes > in server type boxes (intel/matrox...). Otherwise the box is equipped with > lots of cpu > power. This is something that you will find a lot in that major > engineering application > environment. Your application will be glad to find the swrast renderer > that is finally > more capable than the 'GPU' mostly there to drive an administration > console. > You do not want to lock a swrast 'device' (or however you want to call it) > out by > a may be less capable 'console GPU'. > > Beside that having a second type of 'normalized renderer' like Eric was > telling > about is an other one. > > As well as sometimes it may make sense to utilize the GPU > with one set of work and a second GPU with an other set of work in > parallel. > When you only find a single gpu device in one box, you may be glad to find > a swrast device that you can make use of in parallel with the gpu without > the need > to put up different code paths in your application. > > May be I can come up with other cases, but thats the 5 minutes for now ... > > best > > Mathias > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
Hi Marek, On Wednesday, 24 April 2019 02:01:42 CEST Marek Olšák wrote: > Adam, did you notice my original suggestion "If there is at least 1 drm > device, swrast won't be in the list."? which means swrast would be in the > list for your "dumb" GPUs. Imagine a box with a low end drm capable hardware chip like you find sometimes in server type boxes (intel/matrox...). Otherwise the box is equipped with lots of cpu power. This is something that you will find a lot in that major engineering application environment. Your application will be glad to find the swrast renderer that is finally more capable than the 'GPU' mostly there to drive an administration console. You do not want to lock a swrast 'device' (or however you want to call it) out by a may be less capable 'console GPU'. Beside that having a second type of 'normalized renderer' like Eric was telling about is an other one. As well as sometimes it may make sense to utilize the GPU with one set of work and a second GPU with an other set of work in parallel. When you only find a single gpu device in one box, you may be glad to find a swrast device that you can make use of in parallel with the gpu without the need to put up different code paths in your application. May be I can come up with other cases, but thats the 5 minutes for now ... best Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
Adam, did you notice my original suggestion "If there is at least 1 drm device, swrast won't be in the list."? which means swrast would be in the list for your "dumb" GPUs. Marek On Tue, Apr 23, 2019 at 7:52 PM Adam Jackson wrote: > On Tue, 2019-04-23 at 19:21 -0400, Marek Olšák wrote: > > > Then I think a separate EGL extension that exposes swrast would be > > better. The thing with the device extensions is that swrast is not a > > device. > > Enh. I've got dumb GPUs I need to support, they need to run OpenGL, and > if they were running swrast-on-otherwise-dumb-gem, I can make posting > the front buffer to the compositor be (at least sometimes) zero-copy, > instead of the XPutImage thing that drisw currently has to do. So I > don't think it's necessarily the case that swrast doesn't have > "hardware" support behind it. > > More generally, if the term in the extension spec was "renderer" not > "device" I don't think we'd be having this discussion. And I think it's > worth having renderer selection be orthogonal in an API sense. > > - ajax > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
On Tue, 2019-04-23 at 19:21 -0400, Marek Olšák wrote: > Then I think a separate EGL extension that exposes swrast would be > better. The thing with the device extensions is that swrast is not a > device. Enh. I've got dumb GPUs I need to support, they need to run OpenGL, and if they were running swrast-on-otherwise-dumb-gem, I can make posting the front buffer to the compositor be (at least sometimes) zero-copy, instead of the XPutImage thing that drisw currently has to do. So I don't think it's necessarily the case that swrast doesn't have "hardware" support behind it. More generally, if the term in the extension spec was "renderer" not "device" I don't think we'd be having this discussion. And I think it's worth having renderer selection be orthogonal in an API sense. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
On Tue, Apr 23, 2019 at 6:30 PM Eric Anholt wrote: > Marek Olšák writes: > > > On Tue, Apr 23, 2019 at 4:39 PM Mathias Fröhlich < > mathias.froehl...@gmx.net> > > wrote: > > > >> Hi, > >> > >> On Tuesday, 23 April 2019 22:23:45 CEST Marek Olšák wrote: > >> > On Tue, Apr 23, 2019 at 4:05 PM Mathias Fröhlich < > >> mathias.froehl...@gmx.net> > >> > wrote: > >> > > >> > > Hi Marek, > >> > > > >> > > On Tuesday, 23 April 2019 20:22:15 CEST Marek Olšák wrote: > >> > > > I'd like to remove swrast from devices. It doesn't work > >> (eglInitialize > >> > > > fails) and I don't think I like swrast there. Any objections? > >> > > > >> > > Yes, how do you guarantee that at least one device can be returned > >> > > in any case? Even if no drm device is found? > >> > > The egl device query extension guarantees that there is at least one > >> > > device available. > >> > > Beside that swrast may make sense for itself, that is the reason > >> > > the swrast device is there. > >> > > > >> > > >> > If no device can be returned, the extension won't be exposed. > >> Yes, I was triggering this solution back in the days. There was (is?) no > >> infrastructure to enable > >> or disable an egl extension just past initialization or at runtime. > >> Finally Emil took the route to add swrast. > >> > >> The longer I saw the swrast device the better It appeared to me. > >> ... from the users point of view. > >> > >> >OR > >> > If there is at least 1 drm device, swrast won't be in the list. > >> > > >> > From my perspective, radeonsi is always in the list and I wouldn't > like > >> > swrast to be in the list if radeonsi is in the list. > >> > >> I see - at least I think. But really the swrast device is good as is. I > >> see plenty use cases for that. > >> Having that only present when there is no hardware device makes it less > >> useful. > >> > > > > How is swrast good? How is swrast useful if you have a supported GPU? > > EGL has the possibility of finally displacing OSMesa if we can expose > swrast devices. People doing regression testing of higher-level > software stacks (xserver, servo, etc.) need a consistent rasterizer they > can use regardless of the hardware a developer might happen to have on > their desktop. > Then I think a separate EGL extension that exposes swrast would be better. The thing with the device extensions is that swrast is not a device. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
Marek Olšák writes: > On Tue, Apr 23, 2019 at 4:39 PM Mathias Fröhlich > wrote: > >> Hi, >> >> On Tuesday, 23 April 2019 22:23:45 CEST Marek Olšák wrote: >> > On Tue, Apr 23, 2019 at 4:05 PM Mathias Fröhlich < >> mathias.froehl...@gmx.net> >> > wrote: >> > >> > > Hi Marek, >> > > >> > > On Tuesday, 23 April 2019 20:22:15 CEST Marek Olšák wrote: >> > > > I'd like to remove swrast from devices. It doesn't work >> (eglInitialize >> > > > fails) and I don't think I like swrast there. Any objections? >> > > >> > > Yes, how do you guarantee that at least one device can be returned >> > > in any case? Even if no drm device is found? >> > > The egl device query extension guarantees that there is at least one >> > > device available. >> > > Beside that swrast may make sense for itself, that is the reason >> > > the swrast device is there. >> > > >> > >> > If no device can be returned, the extension won't be exposed. >> Yes, I was triggering this solution back in the days. There was (is?) no >> infrastructure to enable >> or disable an egl extension just past initialization or at runtime. >> Finally Emil took the route to add swrast. >> >> The longer I saw the swrast device the better It appeared to me. >> ... from the users point of view. >> >> >OR >> > If there is at least 1 drm device, swrast won't be in the list. >> > >> > From my perspective, radeonsi is always in the list and I wouldn't like >> > swrast to be in the list if radeonsi is in the list. >> >> I see - at least I think. But really the swrast device is good as is. I >> see plenty use cases for that. >> Having that only present when there is no hardware device makes it less >> useful. >> > > How is swrast good? How is swrast useful if you have a supported GPU? EGL has the possibility of finally displacing OSMesa if we can expose swrast devices. People doing regression testing of higher-level software stacks (xserver, servo, etc.) need a consistent rasterizer they can use regardless of the hardware a developer might happen to have on their desktop. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
On Tue, Apr 23, 2019 at 4:39 PM Mathias Fröhlich wrote: > Hi, > > On Tuesday, 23 April 2019 22:23:45 CEST Marek Olšák wrote: > > On Tue, Apr 23, 2019 at 4:05 PM Mathias Fröhlich < > mathias.froehl...@gmx.net> > > wrote: > > > > > Hi Marek, > > > > > > On Tuesday, 23 April 2019 20:22:15 CEST Marek Olšák wrote: > > > > I'd like to remove swrast from devices. It doesn't work > (eglInitialize > > > > fails) and I don't think I like swrast there. Any objections? > > > > > > Yes, how do you guarantee that at least one device can be returned > > > in any case? Even if no drm device is found? > > > The egl device query extension guarantees that there is at least one > > > device available. > > > Beside that swrast may make sense for itself, that is the reason > > > the swrast device is there. > > > > > > > If no device can be returned, the extension won't be exposed. > Yes, I was triggering this solution back in the days. There was (is?) no > infrastructure to enable > or disable an egl extension just past initialization or at runtime. > Finally Emil took the route to add swrast. > > The longer I saw the swrast device the better It appeared to me. > ... from the users point of view. > > >OR > > If there is at least 1 drm device, swrast won't be in the list. > > > > From my perspective, radeonsi is always in the list and I wouldn't like > > swrast to be in the list if radeonsi is in the list. > > I see - at least I think. But really the swrast device is good as is. I > see plenty use cases for that. > Having that only present when there is no hardware device makes it less > useful. > How is swrast good? How is swrast useful if you have a supported GPU? Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
Hi, On Tuesday, 23 April 2019 22:23:45 CEST Marek Olšák wrote: > On Tue, Apr 23, 2019 at 4:05 PM Mathias Fröhlich > wrote: > > > Hi Marek, > > > > On Tuesday, 23 April 2019 20:22:15 CEST Marek Olšák wrote: > > > I'd like to remove swrast from devices. It doesn't work (eglInitialize > > > fails) and I don't think I like swrast there. Any objections? > > > > Yes, how do you guarantee that at least one device can be returned > > in any case? Even if no drm device is found? > > The egl device query extension guarantees that there is at least one > > device available. > > Beside that swrast may make sense for itself, that is the reason > > the swrast device is there. > > > > If no device can be returned, the extension won't be exposed. Yes, I was triggering this solution back in the days. There was (is?) no infrastructure to enable or disable an egl extension just past initialization or at runtime. Finally Emil took the route to add swrast. The longer I saw the swrast device the better It appeared to me. ... from the users point of view. >OR > If there is at least 1 drm device, swrast won't be in the list. > > From my perspective, radeonsi is always in the list and I wouldn't like > swrast to be in the list if radeonsi is in the list. I see - at least I think. But really the swrast device is good as is. I see plenty use cases for that. Having that only present when there is no hardware device makes it less useful. What I don't like with the current solution is that you get the swrast as the first device on the list. The usual application that I know of just uses something closely derived from the nvidia sample code. And that one just takes the first device. So I personally want to make sure that the first device is a hardware accelerated device. Putting the swrast device at the end of the list would be sufficient I think. best Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
On Tue, Apr 23, 2019 at 4:05 PM Mathias Fröhlich wrote: > Hi Marek, > > On Tuesday, 23 April 2019 20:22:15 CEST Marek Olšák wrote: > > I'd like to remove swrast from devices. It doesn't work (eglInitialize > > fails) and I don't think I like swrast there. Any objections? > > Yes, how do you guarantee that at least one device can be returned > in any case? Even if no drm device is found? > The egl device query extension guarantees that there is at least one > device available. > Beside that swrast may make sense for itself, that is the reason > the swrast device is there. > If no device can be returned, the extension won't be exposed. OR If there is at least 1 drm device, swrast won't be in the list. >From my perspective, radeonsi is always in the list and I wouldn't like swrast to be in the list if radeonsi is in the list. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
Hi Marek, On Tuesday, 23 April 2019 20:22:15 CEST Marek Olšák wrote: > I'd like to remove swrast from devices. It doesn't work (eglInitialize > fails) and I don't think I like swrast there. Any objections? Yes, how do you guarantee that at least one device can be returned in any case? Even if no drm device is found? The egl device query extension guarantees that there is at least one device available. Beside that swrast may make sense for itself, that is the reason the swrast device is there. Also, I think I found what crashes. Finally a test bug. The change to piglit is sent to that list. I cleaned up the patch series with the egl extension a bit on my gitlab repo. That with the updated test seems to work here. Still, it would be good if you could test the part that changes the visuals and the pbuffers. best Mathias > > Marek > > On Wed, Apr 17, 2019 at 12:38 AM Mathias Fröhlich > wrote: > > > > > Hi, > > > > On Tuesday, 16 April 2019 17:50:33 CEST Marek Olšák wrote: > > > On Wed, Apr 10, 2019 at 5:37 AM Mathias Fröhlich < > > mathias.froehl...@gmx.net> > > > wrote: > > > > > > > Hi Emil, > > > > > > > > On Monday, 8 April 2019 12:28:55 CEST Emil Velikov wrote: > > > > > > Now that I have been putting together a test case for the the > > actual > > > > use > > > > > > I do see some issues with the pbuffer code path. Well - still > > > > investigating > > > > > > if the test is wrong or the result. > > > > > > > > > > > Actually I do recall some issues with surfaceless (which is > > > > > practically identical to this code) and some (with alpha?) formats. > > > > > My memory is pretty flaky - I would suggest trying various configs: > > > > > with, w/o alpha, 32/24 etc. > > > > > > > > Ok, yesterday evening I spent some time to look into that. > > > > Finally the egl config mechanism puts double buffer visuals > > > > to the pbuffer surface which in turn makes mesa think if should look > > > > at the back buffer which is in turn not set in the pbuffer > > gl_framebuffer. > > > > That one makes my drivers just throw away the rendering result so a > > > > read back does not show anything usable. > > > > > > > > With that fixed I get in principle correct results. > > > > > > > > My gitlab repo contains a branch that sketches my quick fix that I use > > to > > > > make > > > > at least the new piglit test case work. No further testing done. > > > > But may be that helps in getting something reasonable out. > > > > > > > > > > So we can push this series now, right? > > > > Have you been looking at that branch? > > > > Its a sketch at best, and under some circumstance it still crashes > > somewhere > > in the back and forth of virtual methods in the loader and driver. > > I think it's going the riht direction, but until that is fixed I don't > > want to have my > > name tag on that unfinished stuff. > > > > If you want to help out, you can take a look at the egl config change in > > that branch. One needs to check if that 'double buffering visual' filter > > there > > works as expected. Throw test cases at it. At least punch that code through > > piglit and whatever test suite you have access. > > > > best > > > > Mathias > > > > > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
I'd like to remove swrast from devices. It doesn't work (eglInitialize fails) and I don't think I like swrast there. Any objections? Marek On Wed, Apr 17, 2019 at 12:38 AM Mathias Fröhlich wrote: > > Hi, > > On Tuesday, 16 April 2019 17:50:33 CEST Marek Olšák wrote: > > On Wed, Apr 10, 2019 at 5:37 AM Mathias Fröhlich < > mathias.froehl...@gmx.net> > > wrote: > > > > > Hi Emil, > > > > > > On Monday, 8 April 2019 12:28:55 CEST Emil Velikov wrote: > > > > > Now that I have been putting together a test case for the the > actual > > > use > > > > > I do see some issues with the pbuffer code path. Well - still > > > investigating > > > > > if the test is wrong or the result. > > > > > > > > > Actually I do recall some issues with surfaceless (which is > > > > practically identical to this code) and some (with alpha?) formats. > > > > My memory is pretty flaky - I would suggest trying various configs: > > > > with, w/o alpha, 32/24 etc. > > > > > > Ok, yesterday evening I spent some time to look into that. > > > Finally the egl config mechanism puts double buffer visuals > > > to the pbuffer surface which in turn makes mesa think if should look > > > at the back buffer which is in turn not set in the pbuffer > gl_framebuffer. > > > That one makes my drivers just throw away the rendering result so a > > > read back does not show anything usable. > > > > > > With that fixed I get in principle correct results. > > > > > > My gitlab repo contains a branch that sketches my quick fix that I use > to > > > make > > > at least the new piglit test case work. No further testing done. > > > But may be that helps in getting something reasonable out. > > > > > > > So we can push this series now, right? > > Have you been looking at that branch? > > Its a sketch at best, and under some circumstance it still crashes > somewhere > in the back and forth of virtual methods in the loader and driver. > I think it's going the riht direction, but until that is fixed I don't > want to have my > name tag on that unfinished stuff. > > If you want to help out, you can take a look at the egl config change in > that branch. One needs to check if that 'double buffering visual' filter > there > works as expected. Throw test cases at it. At least punch that code through > piglit and whatever test suite you have access. > > best > > Mathias > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
Hi, On Tuesday, 16 April 2019 17:50:33 CEST Marek Olšák wrote: > On Wed, Apr 10, 2019 at 5:37 AM Mathias Fröhlich > wrote: > > > Hi Emil, > > > > On Monday, 8 April 2019 12:28:55 CEST Emil Velikov wrote: > > > > Now that I have been putting together a test case for the the actual > > use > > > > I do see some issues with the pbuffer code path. Well - still > > investigating > > > > if the test is wrong or the result. > > > > > > > Actually I do recall some issues with surfaceless (which is > > > practically identical to this code) and some (with alpha?) formats. > > > My memory is pretty flaky - I would suggest trying various configs: > > > with, w/o alpha, 32/24 etc. > > > > Ok, yesterday evening I spent some time to look into that. > > Finally the egl config mechanism puts double buffer visuals > > to the pbuffer surface which in turn makes mesa think if should look > > at the back buffer which is in turn not set in the pbuffer gl_framebuffer. > > That one makes my drivers just throw away the rendering result so a > > read back does not show anything usable. > > > > With that fixed I get in principle correct results. > > > > My gitlab repo contains a branch that sketches my quick fix that I use to > > make > > at least the new piglit test case work. No further testing done. > > But may be that helps in getting something reasonable out. > > > > So we can push this series now, right? Have you been looking at that branch? Its a sketch at best, and under some circumstance it still crashes somewhere in the back and forth of virtual methods in the loader and driver. I think it's going the riht direction, but until that is fixed I don't want to have my name tag on that unfinished stuff. If you want to help out, you can take a look at the egl config change in that branch. One needs to check if that 'double buffering visual' filter there works as expected. Throw test cases at it. At least punch that code through piglit and whatever test suite you have access. best Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
On Wed, Apr 10, 2019 at 5:37 AM Mathias Fröhlich wrote: > Hi Emil, > > On Monday, 8 April 2019 12:28:55 CEST Emil Velikov wrote: > > > Now that I have been putting together a test case for the the actual > use > > > I do see some issues with the pbuffer code path. Well - still > investigating > > > if the test is wrong or the result. > > > > > Actually I do recall some issues with surfaceless (which is > > practically identical to this code) and some (with alpha?) formats. > > My memory is pretty flaky - I would suggest trying various configs: > > with, w/o alpha, 32/24 etc. > > Ok, yesterday evening I spent some time to look into that. > Finally the egl config mechanism puts double buffer visuals > to the pbuffer surface which in turn makes mesa think if should look > at the back buffer which is in turn not set in the pbuffer gl_framebuffer. > That one makes my drivers just throw away the rendering result so a > read back does not show anything usable. > > With that fixed I get in principle correct results. > > My gitlab repo contains a branch that sketches my quick fix that I use to > make > at least the new piglit test case work. No further testing done. > But may be that helps in getting something reasonable out. > So we can push this series now, right? Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
Hi Emil, On Monday, 8 April 2019 12:28:55 CEST Emil Velikov wrote: > > Now that I have been putting together a test case for the the actual use > > I do see some issues with the pbuffer code path. Well - still investigating > > if the test is wrong or the result. > > > Actually I do recall some issues with surfaceless (which is > practically identical to this code) and some (with alpha?) formats. > My memory is pretty flaky - I would suggest trying various configs: > with, w/o alpha, 32/24 etc. Ok, yesterday evening I spent some time to look into that. Finally the egl config mechanism puts double buffer visuals to the pbuffer surface which in turn makes mesa think if should look at the back buffer which is in turn not set in the pbuffer gl_framebuffer. That one makes my drivers just throw away the rendering result so a read back does not show anything usable. With that fixed I get in principle correct results. My gitlab repo contains a branch that sketches my quick fix that I use to make at least the new piglit test case work. No further testing done. But may be that helps in getting something reasonable out. best Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
On Fri, 5 Apr 2019 at 14:57, Mathias Fröhlich wrote:
>
> Hi Emil,
>
> Now that I have been putting together a test case for the the actual use
> I do see some issues with the pbuffer code path. Well - still investigating
> if the test is wrong or the result.
>
Actually I do recall some issues with surfaceless (which is
practically identical to this code) and some (with alpha?) formats.
My memory is pretty flaky - I would suggest trying various configs:
with, w/o alpha, 32/24 etc.
> In the mean time some small comments inline below ...
>
> Mathias
>
> > --- a/src/egl/Android.mk
> > +++ b/src/egl/Android.mk
> > @@ -36,6 +36,7 @@ include $(CLEAR_VARS)
> > LOCAL_SRC_FILES := \
> > $(LIBEGL_C_FILES) \
> > $(dri2_backend_core_FILES) \
> > + drivers/dri2/platform_android.c \
> > drivers/dri2/platform_android.c
>
> That one duplicates the file.
> The hunk is probably no longer needed?
>
That should have been "platform_device.c" - fixed locally.
> > + /* Extension requires a PlatformDisplay - the EGLDevice. */
> > + dev = disp->PlatformDisplay;
> > + if (_eglDeviceSupports(dev, _EGL_DEVICE_DRM)) {
> > + if (!disp->Options.ForceSoftware)
>
> if (disp->Options.ForceSoftware)
>
> The '!' in your code appears wrong to me.
>
Indeed it does. Fixed locally.
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
Hi Emil,
Now that I have been putting together a test case for the the actual use
I do see some issues with the pbuffer code path. Well - still investigating
if the test is wrong or the result.
In the mean time some small comments inline below ...
Mathias
On Thursday, 4 April 2019 17:25:28 CEST Emil Velikov wrote:
> This new 'platform' is added by default with no guards.
>
> It is effectively a copy of the surfaceless one, with updated function
> names and brand new probe function.
>
> Due to the reuse, some of the ifdef HAVE_SURFACELESS_PLATFORM guards
> have been dropped.
>
> A worthy mention are the changes in _egFindDisplay, since the original
> and dup'd fd are required, we make use of the plat_opt argument.
>
> Note that no hacks for eglGetDisplay are added - the API works only with
> the eglGetPlatformDisplay* API.
>
> v3:
> - s/dpy/disp/g
> - drop swap_buffers* callbacks
> - drop loader_set_logger()
> - drop local define
> - re-introduce _eglGetDRMDeviceRenderNode()
> - EGL_WARN on ForceSoftware with HW device - continue using the HW device
> - bail out for "EGL_MESA_device_software" until it's fixed
> - wire-up the Android build
>
> v2:
> - s/_eglCompareDeviceDisplay/_eglSameDeviceDisplay/ (Eric)
> - let ^^ return bool (Eric)
> - fixup meson build, move files() further up (Eric)
> - copy from plat. surfaceless w/o the visual cleanups
> - close and free when destroying the dpy
> - sprinkle a few _eglDeviceSupports
> - split fd handling into separate function
> - use directly the render node if no FD is given (Mathias)
>
> Cc: Mathias Fröhlich
> Cc: Marek Olšák
> Signed-off-by: Emil Velikov
> ---
> src/egl/Android.mk | 1 +
> src/egl/Makefile.am| 3 +
> src/egl/drivers/dri2/egl_dri2.c| 3 +
> src/egl/drivers/dri2/egl_dri2.h| 13 +-
> src/egl/drivers/dri2/platform_device.c | 388 +
> src/egl/main/eglapi.c | 13 +-
> src/egl/main/egldevice.c | 16 +
> src/egl/main/egldevice.h | 3 +
> src/egl/main/egldisplay.c | 109 ++-
> src/egl/main/egldisplay.h | 11 +
> src/egl/main/eglglobals.c | 1 +
> src/egl/meson.build| 1 +
> 12 files changed, 550 insertions(+), 12 deletions(-)
> create mode 100644 src/egl/drivers/dri2/platform_device.c
>
> diff --git a/src/egl/Android.mk b/src/egl/Android.mk
> index a9319f56ae7..6c886a5aefb 100644
> --- a/src/egl/Android.mk
> +++ b/src/egl/Android.mk
> @@ -36,6 +36,7 @@ include $(CLEAR_VARS)
> LOCAL_SRC_FILES := \
> $(LIBEGL_C_FILES) \
> $(dri2_backend_core_FILES) \
> + drivers/dri2/platform_android.c \
> drivers/dri2/platform_android.c
That one duplicates the file.
The hunk is probably no longer needed?
>
> LOCAL_CFLAGS := \
> diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
> index 349779feb4e..6a74e692b59 100644
> --- a/src/egl/Makefile.am
> +++ b/src/egl/Makefile.am
> @@ -106,6 +106,9 @@ if HAVE_PLATFORM_SURFACELESS
> dri2_backend_FILES += drivers/dri2/platform_surfaceless.c
> endif
>
> +# Unconditionally enable platform_device
> +dri2_backend_FILES += drivers/dri2/platform_device.c
> +
> if HAVE_PLATFORM_ANDROID
> AM_CFLAGS += $(ANDROID_CFLAGS)
> libEGL_common_la_LIBADD += $(ANDROID_LIBS)
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index 6acc99aa62a..d0e8a70b48e 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -874,6 +874,9 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp)
> case _EGL_PLATFORM_SURFACELESS:
>ret = dri2_initialize_surfaceless(drv, disp);
>break;
> + case _EGL_PLATFORM_DEVICE:
> + ret = dri2_initialize_device(drv, disp);
> + break;
> case _EGL_PLATFORM_X11:
>ret = dri2_initialize_x11(drv, disp);
>break;
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
> index aa143deb867..a4064f04043 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -331,10 +331,10 @@ struct dri2_egl_surface
> } color_buffers[3], *back;
> #endif
>
> -#if defined(HAVE_SURFACELESS_PLATFORM)
> - __DRIimage *front;
> - unsigned int visual;
> -#endif
> + /* surfaceless and device */
> + __DRIimage *front;
> + unsigned int visual;
> +
> int out_fence_fd;
> EGLBoolean enable_out_fence;
> };
> @@ -492,6 +492,11 @@ dri2_initialize_surfaceless(_EGLDriver *drv, _EGLDisplay
> *disp)
> }
> #endif
>
> +EGLBoolean
> +dri2_initialize_device(_EGLDriver *drv, _EGLDisplay *disp);
> +static inline void
> +dri2_teardown_device(struct dri2_egl_display *dri2_dpy) { /* noop */ }
> +
> void
> dri2_flush_drawable_for_swapbuffers(_EGLDisplay *disp, _EGLSurface *draw);
>
> diff --git a/src/egl/drivers/dri2/platform_device.c
>
[Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
This new 'platform' is added by default with no guards.
It is effectively a copy of the surfaceless one, with updated function
names and brand new probe function.
Due to the reuse, some of the ifdef HAVE_SURFACELESS_PLATFORM guards
have been dropped.
A worthy mention are the changes in _egFindDisplay, since the original
and dup'd fd are required, we make use of the plat_opt argument.
Note that no hacks for eglGetDisplay are added - the API works only with
the eglGetPlatformDisplay* API.
v3:
- s/dpy/disp/g
- drop swap_buffers* callbacks
- drop loader_set_logger()
- drop local define
- re-introduce _eglGetDRMDeviceRenderNode()
- EGL_WARN on ForceSoftware with HW device - continue using the HW device
- bail out for "EGL_MESA_device_software" until it's fixed
- wire-up the Android build
v2:
- s/_eglCompareDeviceDisplay/_eglSameDeviceDisplay/ (Eric)
- let ^^ return bool (Eric)
- fixup meson build, move files() further up (Eric)
- copy from plat. surfaceless w/o the visual cleanups
- close and free when destroying the dpy
- sprinkle a few _eglDeviceSupports
- split fd handling into separate function
- use directly the render node if no FD is given (Mathias)
Cc: Mathias Fröhlich
Cc: Marek Olšák
Signed-off-by: Emil Velikov
---
src/egl/Android.mk | 1 +
src/egl/Makefile.am| 3 +
src/egl/drivers/dri2/egl_dri2.c| 3 +
src/egl/drivers/dri2/egl_dri2.h| 13 +-
src/egl/drivers/dri2/platform_device.c | 388 +
src/egl/main/eglapi.c | 13 +-
src/egl/main/egldevice.c | 16 +
src/egl/main/egldevice.h | 3 +
src/egl/main/egldisplay.c | 109 ++-
src/egl/main/egldisplay.h | 11 +
src/egl/main/eglglobals.c | 1 +
src/egl/meson.build| 1 +
12 files changed, 550 insertions(+), 12 deletions(-)
create mode 100644 src/egl/drivers/dri2/platform_device.c
diff --git a/src/egl/Android.mk b/src/egl/Android.mk
index a9319f56ae7..6c886a5aefb 100644
--- a/src/egl/Android.mk
+++ b/src/egl/Android.mk
@@ -36,6 +36,7 @@ include $(CLEAR_VARS)
LOCAL_SRC_FILES := \
$(LIBEGL_C_FILES) \
$(dri2_backend_core_FILES) \
+ drivers/dri2/platform_android.c \
drivers/dri2/platform_android.c
LOCAL_CFLAGS := \
diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
index 349779feb4e..6a74e692b59 100644
--- a/src/egl/Makefile.am
+++ b/src/egl/Makefile.am
@@ -106,6 +106,9 @@ if HAVE_PLATFORM_SURFACELESS
dri2_backend_FILES += drivers/dri2/platform_surfaceless.c
endif
+# Unconditionally enable platform_device
+dri2_backend_FILES += drivers/dri2/platform_device.c
+
if HAVE_PLATFORM_ANDROID
AM_CFLAGS += $(ANDROID_CFLAGS)
libEGL_common_la_LIBADD += $(ANDROID_LIBS)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 6acc99aa62a..d0e8a70b48e 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -874,6 +874,9 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp)
case _EGL_PLATFORM_SURFACELESS:
ret = dri2_initialize_surfaceless(drv, disp);
break;
+ case _EGL_PLATFORM_DEVICE:
+ ret = dri2_initialize_device(drv, disp);
+ break;
case _EGL_PLATFORM_X11:
ret = dri2_initialize_x11(drv, disp);
break;
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index aa143deb867..a4064f04043 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -331,10 +331,10 @@ struct dri2_egl_surface
} color_buffers[3], *back;
#endif
-#if defined(HAVE_SURFACELESS_PLATFORM)
- __DRIimage *front;
- unsigned int visual;
-#endif
+ /* surfaceless and device */
+ __DRIimage *front;
+ unsigned int visual;
+
int out_fence_fd;
EGLBoolean enable_out_fence;
};
@@ -492,6 +492,11 @@ dri2_initialize_surfaceless(_EGLDriver *drv, _EGLDisplay
*disp)
}
#endif
+EGLBoolean
+dri2_initialize_device(_EGLDriver *drv, _EGLDisplay *disp);
+static inline void
+dri2_teardown_device(struct dri2_egl_display *dri2_dpy) { /* noop */ }
+
void
dri2_flush_drawable_for_swapbuffers(_EGLDisplay *disp, _EGLSurface *draw);
diff --git a/src/egl/drivers/dri2/platform_device.c
b/src/egl/drivers/dri2/platform_device.c
new file mode 100644
index 000..6d95614e93c
--- /dev/null
+++ b/src/egl/drivers/dri2/platform_device.c
@@ -0,0 +1,388 @@
+/*
+ * Mesa 3-D graphics library
+ *
+ * Copyright 2018 Collabora
+ *
+ * Based on platform_surfaceless, which has:
+ *
+ * Copyright (c) 2014 The Chromium OS Authors.
+ * Copyright © 2011 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish,
