[Mesa-dev] scons tnl bug, rfc on removing mesa rtasm.
Alexander von Gluck
kallisti5 at unixzen.com
Mon Jan 23 13:03:25 PST 2012
On 23.01.2012 14:44, Jose Fonseca wrote:
> I don't think that one should introduce a dependency between Mesa and
> Gallium as each should be built without the
> The right way to do this is to move rtasm to side by side w/ MEsa &
> gallium (e.g., src/rtasm), and have Mesa and
> Gallium both depend on it as needed.
This works for me, however is slightly beyond my Mesa level of comfort :).
The patch I submitted does work, and Mesa already has gallium dependencies
in state_tracker.. could we consider my patches ([Mesa-dev] [PATCH 1/2] mesa:
Remove tnl Mesa rtasm dependency, [Mesa-dev] [PATCH 2/2] mesa: Remove rtasm
as it is no longer used) the first portion of the fix with the intent to move
rtasm into a common space a todo?
> Another way is to rename the symbols so that Mesa and Gallium rtasm are
This seems like more of a hack and a lot more work, Mesa's tnl uses
Gallium's rtasm just fine with a few small tweaks.
> However, IMO, rtasm should be eliminated both from mesa and gallium, as
> all its uses should be replaced with LLVM.
For now that's beyond me, a lot of code in mesa uses tnl still (like Haiku!)
and tnl uses rtasm.
> ----- Original Message -----
>> So I've been digging through the assertion error I am getting under
>> and have finally found the issue...
>> The Mesa tnl depends on the Mesa rtasm header
>> however scons never compiles mesa/x86/rtasm/x86sse.c into libmesa.
>> x86/rtasm/x86sse.c is never compiled in, libmesa tnl requires
>> libgallium.a to
>> link into the gallium rtasm code.
>> As the header in mesa/x86/rtasm/x86sse.h doesn't match the Gallium
>> symbols (src/gallium/auxiliary/rtasm/rtasm_x86sse.h), we begin
>> assertion errors as heap is corrupted (mostly when tnl is used)
>> I am playing with fixing this by making tnl rely on gallium's rtasm
>> vs the
>> Mesa one. As tnl is the last thing I can find that uses the Mesa
>> mesa rtasm
>> could even be removed if this works.
>> Does anyone know of any implementations of Mesa this may break?
>> -- Alex
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
More information about the mesa-dev