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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
