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
other.
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
separate.
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.
-- Alex
----- Original Message -----
So I've been digging through the assertion error I am getting under
Haiku
and have finally found the issue...
The Mesa tnl depends on the Mesa rtasm header
(mesa/x86/rtasm/x86sse.h),
however scons never compiles mesa/x86/rtasm/x86sse.c into libmesa.
As
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
rtasm
symbols (src/gallium/auxiliary/rtasm/rtasm_x86sse.h), we begin
getting
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
rtasm...
mesa rtasm
(http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/x86/rtasm)
could even be removed if this works.
Does anyone know of any implementations of Mesa this may break?
Thanks!
-- Alex
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
