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.
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
