[Mesa-dev] Determinism in the results of llvmpipe?

[Roland Scheidegger]

Am 29.11.2016 um 15:18 schrieb Jose Fonseca:
> 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 <jfonseca at vmware.com>
>>> 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
>>>>> mesa-dev at lists.freedesktop.org
>>>>> 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.
> 

IIRC the "randomness" had no actual random bits in it, so as long as the
same library is used on both machines the results should be the same.
Albeit from the pictures it indeed looks like one has full decoding and
the other not (it's not jist the obvious issues on the "D" but it's not
quite smooth elsewhere neither).

(Albeit I'm not quite sure if you have similar cpus, the  E3-1275 v3 is
Haswell which has AVX2, the CPU E5-2673 v3 doesn't seem to exist or at
least it's not in intel's database - if that's a v2 instead it would be
Ivy Bridge lacking AVX2, just featuring AVX1. In this case you can still
get slightly different results from texture sampling due to potentially
different choice of AoS vs. SoA sampling, albeit nothing which would
explain what you're seeing unless there's a bug somewhere...)

Roland