The Mac OS X SCons build failed on 32-bit CPUs starting with commit
2f6d47a7c8 during linking of graw-null.
The build succeeds though on a 64-bit CPU. See FDO bug 29117.
This was the compiler error.
scons: building associated VariantDir targets: build/darwin-x86-debug
Linking build/darwin-x86-debug/gallium/targets/graw-null/libgraw.dylib ...
Undefined symbols:
"_lp_swizzled_cbuf", referenced from:
_lp_swizzled_cbuf$non_lazy_ptr in libllvmpipe.a(lp_rast.os)
_lp_swizzled_cbuf$non_lazy_ptr in libllvmpipe.a(lp_rast_tri.os)
(maybe you meant: _lp_swizzled_cbuf$non_lazy_ptr)
"_lp_dummy_tile", referenced from:
_lp_dummy_tile$non_lazy_ptr in libllvmpipe.a(lp_rast.os)
_lp_dummy_tile$non_lazy_ptr in libllvmpipe.a(lp_rast_tri.os)
_lp_dummy_tile$non_lazy_ptr in libllvmpipe.a(lp_setup.os)
(maybe you meant: _lp_dummy_tile$non_lazy_ptr)
The patch adds -fno-common to all Mac OS X builds to work around this issue.
DRI2 events are sent to the X drawable ID used to create the DRI2 drawable,
not the GLX drawable ID. So when an event comes in, we need to look up
the __GLXDRIdrawable by its X drawable ID, which needs a new hash table.
Use a single swizzled tile per colorbuf (and per thread) to avoid
accumulating large amounts of cached swizzled data.
Now that the SSE3 code has been merged to master, the performance delta
of this change is minimal, the main benefit is reduced memory usage
due to no longer keeping swizzled copies of render targets.
It's clear from the performance of the in-place version of this code
that there is still quite a bit of time being spent swizzling &
unswizzling, but it's not clear exactly how to reduce that.
The translate_prim() function tries to convert quad strips into
tri strips. This is normally OK but we have to check for an odd
number of vertices so that we don't accidentally draw an extra
triangle. The mesa-demos/src/samples/prim.c demo exercises that.
With this fix the stray yellow triangle is no longer drawn.
Use the u_trim_pipe_prim() function to make sure that prims have
the right number of vertices and avoid calling gallium drawing
functions when the prim has a degenerate number of vertices.
Plus add comments, clean-up formatting, etc.
NOTE: This is a candidate for the 7.8 branch.