summaryrefslogtreecommitdiff
path: root/src/gallium/targets/libgl-xlib
AgeCommit message (Collapse)Author
2010-05-12rbug: Add to all targets that link against traceJakob Bornecrantz
Also added calls to the create function in target helpers and in tr_drm.c the latter being a hack and should be replaced with the wrap screen target helper. But at least this way we don't regress.
2010-05-07glapi: Move to src/mapi/.Chia-I Wu
Move glapi to src/mapi/{glapi,es1api,es2api}.
2010-04-26st_api: Remove st_moduleJakob Bornecrantz
The struct st_module isn't needed as it is the same thing as the st_api struct. That is they both represent the API. Instead just use a single function entry point to the the API.
2010-04-19Merge branch '7.8'Dan Nicholson
Conflicts: progs/egl/Makefile progs/egl/Makefile is gone on master with the egl demos split into subdirectories. Will require an additional commit.
2010-04-11scons: Always build softpipe and llvmpipe (when llvm available).José Fonseca
These are our reference software rasterizers. They can build everywhere and are a precious debugging tool. Making them always present immensily simplifies the scons logic. If people want to avoid building it is still possible to pass direcotries and target names to scons to narrow the build.
2010-04-11scons: Make LLVM a black-white dependency.José Fonseca
Now that draw depends on llvm it is very difficult to correctly handle broken llvm installations. Either the user requests LLVM and it needs to supply a working installation. Or it doesn't, and it gets no LLVM accelerate pipe drivers.
2010-03-31libgl-xlib: Fix missing X11 symbols.José Fonseca
2010-03-29st/dri/sw: add drisw_api similarly to dri1_apiGeorge Sapountzis
I am pretty sure that this is in gallium spirit, so commit. Thanks to Chia-I for suggesting this.
2010-03-26swrastg: allow for any of the software rasterizers.George Sapountzis
This function should be put in targets/common or winsys/sw/common and shared with targers/libgl-xlib and winsys/sw/drm. For targets/common, you get layering violations in the build system unless all of drm_api's are moved under targets.
2010-03-25gallium: Fix libgl-xlib path to sw xlib winsysJakob Bornecrantz
2010-03-21Revert "gallium: add soft screen helper"George Sapountzis
This reverts commit f87a5f6499f51f651c2a9f2d4682875b22926905.
2010-03-21Revert "fix scons build"George Sapountzis
This reverts commit 29ec05164838f13d9535271796a50fa213d07912.
2010-03-21fix scons buildGeorge Sapountzis
2010-03-21gallium: add soft screen helperGeorge Sapountzis
2010-03-16libgl-xlib: Use a simple GALLIUM_DRIVER env var to select the pipe driver.José Fonseca
GALLIUM_DRIVER is being used in many other places, and it easier to memorizing and understand than all the GALLIUM_NO_XXX.
2010-03-16Merge remote branch 'origin/gallium-st-api'Chia-I Wu
2010-03-15libgl-xlib: Obey GALLIUM_SOFTPIPE define.José Fonseca
2010-03-13st/glx: Make xmesa_create_st_api a callback of xm_driver.Chia-I Wu
Instead of guessing the API in st/glx, let the target decide how to create st_api.
2010-03-12winsys/xlib, st/es: Advertise st_api.h support.Chia-I Wu
This is done by defining one of st_module_OpenGL_ES1, st_module_OpenGL_ES2, and st_module_OpenGL.
2010-03-10target-helpers: remove swrast_xlib.c helperKeith Whitwell
This was a good idea, but ended up tying the build systems in knots. We can revisit this later, in particular if we can put in place dummy implementations of cell_create_screen(), llvmpipe_create_screen() which just return NULL if the driver isn't available. In the meantime, just duplicate this smallish function in the two places it was being called.
2010-03-09gallium: create helper for swrast+xlib combinationKeith Whitwell
Several targets may want to reuse this code. It's pretty simple, not sure if this is really a win.
2010-03-09scons: Fix the libg-xlib Sconscript.José Fonseca
2010-03-09targets/libgl-xlib: add code to inject trace and identity layersKeith Whitwell
Finally we can inject layers for debug, trace and "other" with relative ease between state-tracker and driver.
2010-03-09ws/xlib: remove self-knowledge about users of xlib winsysKeith Whitwell
Several software rasterizers can make use of this winsys, but there isn't any reason why the winsys itself should know about them. This change moves that information into the libgl-xlib target. Need to fix up other targets making use of this winsys.
2010-03-08gallium: introduce target directoryKeith Whitwell
Currently there are still at least two functions bundled up inside the winsys concept: a) that of a backend resource manager, sometimes capable of performing present() operations, b) the initialization code/routine for the whole driver stack. The inclusion of (b) makes it difficult to share implementations of (a) between different drivers. For instance, a clean xlib winsys could be of use for software-rasterized VG, GLES, EGL, etc, stacks. But that is only true as long as there is no dependency from the winsys to higher level code, as would be the case when we include (b) in this component. This change creates a new gallium/targets subtree, specifically for implementing the glue needed to build individual driver stacks, and moves that code out of a single example winsys, namely xlib. Other drivers continue to build unchanged, but hopefully can migrate to this structure over time.