[Mesa-dev] [PATCH 1/2] Unify OpenGL and OpenCL version string suffix

Giuseppe Bilotta giuseppe.bilotta at gmail.com
Tue May 24 07:39:46 UTC 2016


On Tue, May 24, 2016 at 2:26 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 23 May 2016 at 22:11, Giuseppe Bilotta <giuseppe.bilotta at gmail.com> wrote:
>> I'll try. I've never used scons before thought so I might need some
>> guidance along the way. (Doubly so considering that trying to run
>>
>> % scons
>>
>> on my work dir results in a backtrace about tuple not being callable
>> on line 143 of the top-level SConstruct — python2 vs python3 issue
>> maybe? This is on Debian unstable.)
>>
> Having python2 and 3 here. With the python being symlink to python3.
> Haven't had any problems like that. If you cannot get it running,
> please cc Jose (when sending the autoconf patch), he could be
> interested in updating scons.

Apparently the bug is a known issue and Jose is aware of it ;-)

https://bugzilla.freedesktop.org/show_bug.cgi?id=95211

I'll try to install the older version of scons and/or fix the issue myself.

>> Well, that sort-of defeats the whole point of unifying the version
>> string declaration, but it does make sense if we want to be selective
>> about inclusion of the LLVM version string (to the drivers that
>> actually use it).
>>
> I guess that's the part I did not get - why should mesa say "LLVM xxx"
> if said driver does not use it ? Isn't that wrong and/or misleading
> ?For clover, llvmpipe, i915g and the gallium radeons - sure. But none
> of the classic drivers, nouveau, freedreno... is using it so there's
> no need adding it there ?

Mostly I thought about it for consistency. As I just explained in
another reply here, in OpenCL the LLVM version is needed even at the
platform level to identify some possible issues with ICDs with mixed
LLVM versions, and of course it's also useful at the individual driver
level when they use it. From this perspective, putting the LLVM
version in the global Mesa version string makes sense as it gives the
same Mesa version string regardless of API used to access it.

I don't think it's wrong, because it is part of the Mesa build
information, even when it's not directly relevant to the specific
renderer. Note that I'm not unconditionally adding it to all renderer
version strings: those are left untouched.




-- 
Giuseppe "Oblomov" Bilotta


More information about the mesa-dev mailing list