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

[Cherniak, Bruce]

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 <sroland at vmware.com<mailto:sroland at 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 at lists.freedesktop.org<mailto:mesa-dev at lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181129/a91f5ae7/attachment-0001.html>