| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
Keith prefers a clean separation between graw applications and
implementations, where apps do not link libgallium.a but instead
get all functionality they need via graw interface.
Although this is not incompatible with late loading of graw drivers, it
it would make it very hard to maintain, as wrappers for every utility
symbol exposed in graw would have to be written or generated somehow.
|
| |
|
|
|
| |
Pointless now that the graw tests can be built independently of any graw
implementation.
|
| |
|
|
| |
Sconscript could be invoked twice if specified in the command line.
|
| |
|
|
|
|
|
|
|
| |
The target supports OpenVG on Windows with software rasterizer. The
egl_g3d_loader defined by the target supports arbitrary client APIs and
window systems. It is the SConscript that limits the support to OpenVG
and GDI.
This commit also fixes a typo in gdi backend.
|
| | |
|
| |
|
|
| |
It will build api_OpenVG.dll on Windows.
|
| |
|
|
|
| |
egl_gdi_swrast uses st/egl/gdi and winsys/sw/gdi to provide an EGL
driver for Windows.
|
| |
|
|
| |
Fix several portability issues and add SConscript for Windows build.
|
| |
|
|
|
|
| |
Ideally scons should be able to work backwards from the list of
targets to figure out which drivers, state trackers and other
convenience libraries need to be built.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Provides basic window system integration behind a simple interface,
allowing tests to be written without dependency on either the driver
or window system.
With a lot of work, could turn into something like glut for gallium.
|
| |
|
|
|
|
|
| |
When building more then one dri driver we would get warnings because
we where defining the same build target multiple times.
Also move all the dri scons targets related code into its own file.
|
| |
|
|
| |
Since the winsys isn't shared with i965 and never will be
|
| | |
|
| | |
|
| |
|
|
|
| |
This will likely change. Most probably we'll just add an alias to indvidual
targets and use the regular scons targets arguments.
|
|
|
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.
|
