<div dir="ltr"><div>BTW, swrast doesn't have to exist on the system. It's not uncommon for me to have no swrast on my development system. </div><div> </div><div>Marek </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 1, 2019 at 4:30 AM Mathias Fröhlich <<a href="mailto:Mathias.Froehlich@gmx.net">Mathias.Froehlich@gmx.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote: > > > > On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote: > >> > >> On Sat, 27 Apr 2019 09:38:27 -0400 > >> Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> 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 <a href="https://gitlab.freedesktop.org/frohlich/mesa/commits/egl-device-5" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/frohlich/mesa/commits/egl-device-5</a> There are also Mareks latest pbuffer fixes in that branch. Sure that is not a ready to merge patch series... best Mathias </blockquote></div>