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.froehl...@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 <mar...@gmail.com> wrote: > > > > > > > > On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen <ppaala...@gmail.com> > > wrote: > > > >> > > > >> On Sat, 27 Apr 2019 09:38:27 -0400 > > > >> Marek Olšák <mar...@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 > > > > > > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
