those are the only archs that currently use gallium radeon drivers.
It should build anywhere that has the libdrm radeon headers
installed. And while that should really be everywhere it
isn't at the moment and won't be for release.
It isn't clear why the radeon winsys in Mesa 10.4 didn't have
the same problem.
Found the hard way by todd@ on alpha.
This is desirable as the chromium port now uses this extension to
obtain pci vendor/device ids for use in feature/extension blacklists.
Prompted by a mail from byrnet@, tested on r600g by krw@
The newly added os_get_total_physical_memory() was passing the length of
a pointer rather than the type which made the sysctl call fail on
non 64 bit archs. And it was passing the wrong pointer for the result.
Fixes for these problems have been submitted back upstream.
With 10.4.3 gpu compositing on chromium would result in a black window
on older Intel parts (ie x60s with 945gm) and at least some discrete
Radeon parts. These problems do not seem to occur on recent Intel
parts, though those have coherent memory and hardware contexts.
It isn't clear what changes in Mesa are involved in the problem
though it also occurs with the 10.3 branch.
gallium/targets/{r300,r600,radeonsi}/common/drm_target.c in the Mesa source
but cvs import ignores symlinks.
Change the directory we search for drm_target.c in to deal with this.
build the Gallium3D software rasterizer as part of the libGL.
Note that it can also makes use of LLVM to build the llvmpipe if the
corresponding port is installed. Please refer to the README for a more
complete documentation.
Prodded by ajacoutot@, ok matthieu@
driver by default but can also use the llvmpipe driver that use LLVM
for code generation if available.
Not yet linked to the build as it depends on pthreads and we don't know
yet how to handle the switch from the default 'swrast' driver, but having
it in tree will help testing and debugging the remaining issues.
Tested by ajacoutot@ and matthieu@, looks ok to matthieu@
