| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Okay need to revist the whole OQ stuff anyways, glean test asserts
which is never good.
I'm liking the cached bufmgr restrictions less and less, I think I'll
probably play with the fence and/or busy stuff ASAP and try and clean it up.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This adds the cached bufmgr for vertex/index buffers on top of the kernel
manager.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
Slight memory savings, but more importantly also avoids a potential NULL
dereference.
|
|
If we change the tiling on a buffer we need to flush it, the old
radeon_buffer.c code had this but it crossed streams when I ported to
radeon_drm_buffer.c and I missed it. Should fix some piglit regressions.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
|
|
This creates a cleaner winsys and drop the simple screen stuff.
It makes r300g use pb_bufmgr structs.
It also tries to avoid overheads from mapping too often.
v5: clean warnings
v6: break out of cache check on first buffer - since most likely
the first busy one implies all after it are busy.
v7: cleanup a bit
v8-merged: drop cman for now to just get all the interface changes in first.
rework to changes that happened upstream
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This is the last nvfx unification patch.
nv[34]0_fragtex.c are moved to the common directory
nv[34]0_shader.h are renamed to nv[34]0_vertprog.h and moved to
the common directory
The separate nv30 and nv40 directories are removed from the build
system
|
|
The files have the same structure but are substantially different.
They are unified with appropriate conditionals.
|
|
Will be used to hold source files unified between nv30 and nv40.
Eventually all nv30 and nv40 code will be moved there and the
nv30 and nv40 directories will be removed.
|
|
This can break on systems that don't have a system X installation.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
|
|
E.g. when mapping buffers could flush CS or cause waiting
for a busy buffer.
The side effect of this is it also fixes progs/demos/arbocclude however
a separate fix should be proposed to address this issue in other cases
it might occur.
|
|
|
|
|
|
Memory for xm_dt was allocated twice.
|
|
|
|
|
|
|
|
This reverts commit 2d56d0839e6db0861131893d67fe23734800085a.
Never actually used.
|
|
The libraries have circular dependencies. Use --start-group and
--end-group when producing the final shared libraries.
|
|
One where framebuffer data will be read via texture transfers.
Useful for e.g., python state tracker.
|
|
|
|
|
|
|
|
Several targets may want to reuse this code. It's pretty simple, not
sure if this is really a win.
|
|
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.
|
|
The driver is pretty much totally broken though.
|
|
|
|
This will likely change. Most probably we'll just add an alias to indvidual
targets and use the regular scons targets arguments.
|
|
|
|
|
|
|
|
Don't make the shared software winsys rely on internal knowledge about
the cell driver's texture twiddling.
This is just a sketch and hasn't even been compile tested.
|
|
|
|
No need for the user of this winsys to supply/manage the x11 gc for
us.
|
|
Conflicts:
src/gallium/drivers/llvmpipe/lp_setup.c
src/gallium/drivers/softpipe/sp_texture.c
src/gallium/drivers/softpipe/sp_winsys.h
src/gallium/state_trackers/egl/common/egl_g3d.c
src/gallium/state_trackers/egl/x11/native_x11.c
src/gallium/state_trackers/egl/x11/native_x11.h
src/gallium/state_trackers/egl/x11/native_ximage.c
|
|
|
|
|
|
Just use flush_frontbuffer directly. The flush_frontbuffer routine has
been somewhat devalued recently, but it is actually just the right
interface for our needs.
It is in pipe_screen, meaning that any wrapping (eg trace module)
will get properly unwrapped before we try and use the pipe_surface
argument for real.
If a particular co-state-tracker needs to implement this itself, it
should organize a way to allow the winsys to call back up to its
level, rather than hijacking the driver-supplied implementation.
|
|
|
|
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.
|
|
|
|
|
|
Introduce xlib_drawable struct, pass this down to winsys instead of
having it use the internal data structures from glx/x11
|
|
|
|
|
|
|
|
|
