On Wed, Feb 7, 2018 at 1:37 AM, Michel Dänzer wrote:
> For a non-current snapshot of Mesa Git master, one may have to find an
> LLVM SVN snapshot from around the same time.
Just so I understand, a statement like "Try repro'ing the bug in svn
commit x of mesa from last year" doesn't wind up being
On Wed, Feb 7, 2018 at 1:16 AM, Andrew A. wrote:
> Hello,
>
> I often pull down the latest mesa from the git repo and find that I
> have to muck around with building several different llvm versions
> before I find one that mesa will successfully build/link against.
>
> F
Hello,
I often pull down the latest mesa from the git repo and find that I
have to muck around with building several different llvm versions
before I find one that mesa will successfully build/link against.
For any given mesa git revision, how can I find out which llvm version
it should be built
x27;t seem to get any error or warning
messages about this.
It seems like incomplete textures would be a very handy thing to know
about when debugging.
Thanks again,
Andrew
On Wed, Feb 1, 2017 at 5:31 PM, Roland Scheidegger wrote:
> Am 01.02.2017 um 05:32 schrieb Andrew A.:
>> Are t
Are there any known issues with using usampler2D on a GL_R32UI texture
in llvmpipe from within a VS/FS? I'm getting expected results on
Nvidia drivers (proprietary), but not with mesa llvmpipe (always get
zero).
___
mesa-dev mailing list
mesa-dev@lists.fr
> Am 29.11.2016 um 15:18 schrieb Jose Fonseca:
>> 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
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 sam
