| Age | Commit message (Collapse) | Author |
|---|
|
st/egl no longer relies on libGL for OpenGL support.
|
|
If the GALLIUM_GALAHAD env var is 1 we'll wrap the regular driver with
the galahad validation driver.
|
|
Include st_api.h for st_api_create_OpenGL symbol.
|
|
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.
|
|
I am pretty sure that this is in gallium spirit, so commit. Thanks to Chia-I
for suggesting this.
|
|
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.
|
|
This reverts commit f87a5f6499f51f651c2a9f2d4682875b22926905.
|
|
|
|
GALLIUM_DRIVER is being used in many other places, and it easier to
memorizing and understand than all the GALLIUM_NO_XXX.
|
|
|
|
|
|
Instead of guessing the API in st/glx, let the target decide how to
create st_api.
|
|
This is done by defining one of st_module_OpenGL_ES1,
st_module_OpenGL_ES2, and st_module_OpenGL.
|
|
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.
|
|
Several targets may want to reuse this code. It's pretty simple, not
sure if this is really a win.
|
|
Finally we can inject layers for debug, trace and "other" with
relative ease between state-tracker and driver.
|
|
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.
|
|
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.
|
