[Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support

Fri May 3 05:58:02 UTC 2019

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 <Mathias.Froehlich at gmx.net>
> 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 <maraeo at gmail.com> wrote:
> > > >
> > > > On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen <ppaalanen at gmail.com>
> > wrote:
> > > >>
> > > >> On Sat, 27 Apr 2019 09:38:27 -0400
> > > >> Marek Olšák <maraeo at gmail.com> 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 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, if that helps:
> > The tests already work well also with swrast in
> > https://gitlab.freedesktop.org/frohlich/mesa/commits/egl-device-5
> > There are also Mareks latest pbuffer fixes in that branch.
> > Sure that is not a ready to merge patch series...
> >
> > best
> >
> > Mathias
> >
> >
> >
> 