Hello and apologies for such a delayed response — we were quite busy with the SC’18 supercomputing conference.
On Oct 17, 2018, at 3:37 PM, Roland Scheidegger <srol...@vmware.com<mailto:srol...@vmware.com>> wrote: 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). You are correct in the assessment that OpenSWR development has been focused primarily on performance improvements over additional features at this time. If key applications within our "data visualization" focused space require additional features, we will consider those features on a case-by-case basis. 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 interesting.) Indeed, it would be very nice if someone in the community wishes to contribute. :-) 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. The OpenSWR rasterizer core also supports DX10 rasterization rules, tessellation, and far more than we have exposed through the OpenSWR gallium driver. However, the source has become considerably more difficult to fully understand than llvmpipe. 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? The only x86 architecture specific code in OpenSWR should be limited to the SIMD abstraction wrappers (https://gitlab.freedesktop.org/mesa/mesa/tree/master/src/gallium/drivers/swr/rasterizer/common/simdlib*) and a few things in the jitter. Theoretically, non-x86 SIMD abstraction wrappers could be written, but we do not have that expertise, nor the resources. We always appreciate and welcome community contributions, however. Thank you, Bruce many thanks Gert _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
