| Age | Commit message (Collapse) | Author |
|---|
|
|
|
GLES can be enabled by running scons with
$ scons gles=yes
When gles=yes is given, the build is changed in three ways. First,
libmesa.a will be built with FEATURE_ES1 and FEATURE_ES2. This makes
DRI drivers and libEGL support and advertise GLES support. Second, GLES
libraries will be created. They are libGLESv1_CM, libGLESv2, and
libglapi. Last, libGL or opengl32 will link to libglapi. This change
is required as _glapi_* will be declared as __declspec(dllimport) in
libmesa.a on windows. libmesa.a expects those symbols to be defined in
another DLL. Due to this change to GL, GLES support is marked
experimental.
Note that GLES requires libxml2-python to generate some of its sources.
|
|
When --enable-shared-glapi is specified, libGL will share libglapi with
OpenGL ES instead of defining its own copy of glapi. This makes sure an
app will get only one copy of glapi in its address space.
The new option is disabled by default. When enabled, libGL and libglapi
must be built from the same source tree and distributed together. This
requirement comes from the fact that the dispatch offsets used by these
libraries are re-assigned whenever GLAPI XMLs are changed.
For GLX, indirect rendering for has_different_protocol() functions is
tricky. A has_different_protocol() function is assigned only one
dispatch offset, yet each entry point needs a different protocol opcode.
It cannot be supported by the shared glapi. The fix to this is to make
glXGetProcAddress handle such functions specially before calling
_glapi_get_proc_address.
Note that these files are automatically generated/re-generated
src/glx/indirect.c
src/glx/indirect.h
src/mapi/glapi/glapi_mapi_tmp.h
|
|
|
|
|
|
|
|
|
|
Use scons target and dependency system instead of ad-hoc options.
Now is simply a matter of naming what to build. For example:
scons libgl-xlib
scons libgl-gdi
scons graw-progs
scons llvmpipe
and so on. And there is also the possibility of scepcified subdirs, e.g.
scons src/gallium/drivers
If nothing is specified then everything will be build.
There might be some rough corners over the next days. Please bare with me.
|
|
glapidispatch.h exists so that core mesa (libmesa.a) can be built for
DRI drivers or for non-DRI drivers as a compile time decision (whether
IN_DRI_DRIVER is defined). It is of no use to glapi. This commit also
drops the use of glapidispatch.h in glx and libgl-xlib as they are
considered extensions to glapi when it comes to defining public GL
entries.
|
|
Now that MESA_MINOR=10, we no longer need the extra '0' in the
version string.
|
|
st/egl no longer relies on libGL for OpenGL support.
|
|
Check MESA_LLVM and link to LLVM as other targets do.
|
|
If the GALLIUM_GALAHAD env var is 1 we'll wrap the regular driver with
the galahad validation driver.
|
|
glxinfo and glxgears run on swrast and softpipe without undefined symbol
errors.
|
|
Include st_api.h for st_api_create_OpenGL symbol.
|
|
|
|
|
|
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.
|
|
Move glapi to src/mapi/{glapi,es1api,es2api}.
|
|
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.
|
|
Conflicts:
progs/egl/Makefile
progs/egl/Makefile is gone on master with the egl demos split into
subdirectories. Will require an additional commit.
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
This reverts commit 29ec05164838f13d9535271796a50fa213d07912.
|
|
|
|
|
|
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.
|
