On 29/11/16 14:13, Jose Fonseca wrote:
On 29/11/16 14:00, Andrew A. wrote:
On Fri, Nov 18, 2016 at 2:58 AM, Jose Fonseca <[email protected]>
wrote:
On 17/11/16 07:37, Andrew A. wrote:
Hello,
I'm using Mesa's software renderer for the purposes of regression
testing in our graphics software. We render various scenes, save a
screencap of the framebuffer for each scene, then compare those
framebuffer captures to previously known-good captures.
Across runs of these tests on the same hardware, the results seem to
be 100% identical. When running the same tests on a different machine,
results are *slightly* different. It's very similar within a small
tolerance, so this is still usable. However, I was hoping for fully
deterministic behavior, even if the hardware is slightly different.
Are there some compile time settings or some code that I can change to
get Mesa's llvmpipe renderer/rasterizer to be fully deterministic in
its output?
I'm using llvmpipe, and these are the two different CPUs I'm using to
run the tests:
Intel(R) Xeon(R) CPU E3-1275 v3
Intel(R) Xeon(R) CPU X5650
Thanks,
Andrew
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
llvmpipe changes its behavior in _runtime_ based on the CPU features
(like
SSE AVX, AVX2, etc.)
You could hack u_cpu_detect.c and LLVM source code to mask away CPU
extra
features ans reduce the perceived CPUID flags to the common denominator.
In fact, for the two CPUs you mention above, the differences probably go
away if you set this environment variable:
LP_NATIVE_VECTOR_WIDTH=128
as it will force llvmpipe to ignore AVX/AVX2/FMA/F16C.
But probably the best is to use x86 virtualization to clamp CPUID and do
that. Having a virtual machine image will also solve the problem of
ensuring all runtime is the same, etc.
https://software.intel.com/en-us/articles/intel-software-development-emulator
can also do the same without virtualization (via bianry translation),
but it
might impact performance.
Jose
Thanks for all the help. Forcing 128 did indeed produce deterministic
results, but slowed things down enough that I just opted to set up
another machine with AVX for my purposes.
After having done this, I ran into an odd problem: On a scene that
uses a BC1 texture (S3TC_DXT1 in OGL terms), I see strange artifacts
on one machine, whereas I do not on another machine.
Intel(R) Xeon(R) CPU E5-2673 v3 (Running in a VM) has these strange
artifacts (Note around the second "D") -
http://imgur.com/a/sUPVF
Intel(R) Xeon(R) CPU E3-1275 v3 (Running bare metal) has no such
artifacts -
http://imgur.com/a/mONF5
Any hunches on what can cause these kinds of artifacts? I do not
notice these problems with other (non compressed) texture formats that
I've tried.
I'm using mesa 05533ce and llvm 62c10d6.
Thanks,
Andrew
llvmpipe doesn't implement S3TC itself due to patent issues -- it relies
on libtxc-dxtn.
From the artifacts, my guess is that you have one version of
libtxc-dxtn-s2tc0 from https://github.com/divVerent/s2tc -- a
non-conforming implementation of S3TC that avoids the patents --, and
something else on the other.
Thankfully the patents are close to expire and this nightmare should
hopefully end. (Though it makes me feel old every time I think about it.)
Jose
Actually, IIUC https://github.com/divVerent/s2tc/wiki/libtxc_dxtn picks
colors at random, so its possible you have the same version of s2tc
library, but random colors are being picked.
If so, you might to hack s2tc to not pick colors at random, or just
avoid S3TC textures if you can.
Jose
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
