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 <[email protected]> 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 <[email protected]> wrote: > > > > > > On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen <[email protected]> > wrote: > > >> > > >> On Sat, 27 Apr 2019 09:38:27 -0400 > > >> Marek Olšák <[email protected]> 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 [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
