[Mesa-dev] Q: to which software renderers should we contribute to help virgl conformance testing

[Roland Scheidegger]

Am 17.10.18 um 19:15 schrieb Gert Wollny:
> Dear all, 
> 
> we are looking into doing a CI for virglrenderer that also runs a
> subset of the GLES dEQP, and in order to be able to run this also in
> gitlab.fd.o we were looking into the available gallium software
> renderers. Inital tests by just running the dEQP-GLES2 were quite
> successful in the sense that the exection time is not too long (a full
> run on the GL and GLES host with llvmpipe takes about 10 min [1]). 
> 
> Now to extend on that work the focus is turning to which software
> renderer has the most features, the least failing tests, and is
> actively developed. 
> 
> Simply looking at the commit stats it seems that the developement of
> softpipe and llvmpipe is mostly stalled, swr, on the other had has seen
> quite some development, but mostly regarding performance, and given the
> FAQ [2] the focus is on a very specific application space and not so
> much on getting more features in.
I wouldn't quite say llvmpipe is stalled, although it's true that there
weren't all that many changes (in particular as new features are concerned).

> 
> When checking for conformance of virglrenderer we need a host driver
> that is conformant itself, and we are willing to contribute here, but
> it seems to make most sense to focus this work on just one driver. To
> make sensible choice there are some open questions:
> 
> Are there plans to get swr and/or llvmpipe to support gles 3.1, or
> carry any of the drivers even further, maybe GLES 3.2 and desktop 4.x?
At a quick glance for for gles 3.1 llvmpipe would be missing mostly
compute shaders and shader images / ssbo, so definitely some work. GL 4
would add tessellation as well (at least I think these are the big parts
missing).
Unfortunately I don't have time to work on this, but it would be nice to
have indeed. Well volunteers welcome, no special hw nor docs needed :-).
(Although softpipe is easier to work with, but it's just not all that
interesing.)

> 
> 
> Is there any specific interest to fix all failures that occur when
> running gles dEQP? In this bug report [3] Roland pointed out that
> "there is no goal as such to pass dEQP, although patches are welcome",
> any opinion for the other drivers? (for swr beyond what is written in
> the FAQ).
I think it wouldn't really be all that much work to get dEQP passing -
since llvmpipe is built to honor dx10 rules, which are typically more
strict than GL. But some things specific to GL fail. So IMHO if you want
a non-hw driver to pass dEQP, llvmpipe is probably still your best bet
(but of course, softpipe is generally easier to fix).
Can't really comment on swr there.

Roland


> 
> As pointed out in the FAQ, swr is very Intel specific, are there plans
> not layed out in the FAQ to support other, non-x86 hardware?
> 
> many thanks 
> Gert