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@
thereof provided with libdrm. This has been annoying me forever, and it
a blight caused by developing widely used drivers out of the kernel
tree.
ok matthieu@
it, and we're about to switch to using kernel headers instead of the
ones packaged with libdrm. If the unichrome driver gets rewritten (or I
eventually get time), then it'll come back.
ok matthieu@
