| Age | Commit message (Collapse) | Author |
|---|
|
Split hw vs pipe states creation handling as hw states group doesn't
match pipe state group exactly. Right now be dumb about that and
rebuild all hw states on each draw call. More optimization on that
side coming.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
The driver gets a buffer and its size in resource_from_handle.
It computes the required minimum buffer size from given texture
properties, and compares the two sizes.
This is to early detect DDX bugs.
|
|
Also move some initialization from screen init to pre-init, now
that it is possible.
Also import a new vmwgfx drm (1.3) header.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
|
|
allow pipe driver to get the family of the gpu.
|
|
|
|
|
|
Also print relocation failures on non-debug builds too.
|
|
|
|
|
|
|
|
This flush happens when changing the tiling flags, and it should really be
done in the context.
I hope this fixes FDO bug #28630.
|
|
Conflicts:
src/gallium/state_trackers/egl/x11/native_dri2.c
src/gallium/state_trackers/egl/x11/native_x11.c
src/gallium/state_trackers/egl/x11/native_x11.h
src/gallium/state_trackers/xorg/xorg_driver.c
src/gallium/winsys/radeon/drm/radeon_drm.c
|
|
|
|
|
|
|
|
Well sorta, at least I removed the drm_api dependancy and the
target can layer anything it wants to now.
|
|
|
|
|
|
|
|
Currently unconditional and causes segfaults.
|
|
Last user went away
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I have had a look at the libdrm sources and they just contain more or less
the same checking we do in macros, and begin_cs may realloc the CS buffer
if we overflow it, which never happens with r300g. So these are pretty
much useless.
There is a small but measurable performance increase by dropping the two
functions.
|
|
|
|
This is a simple winsys that mmap()s the framebuffer device and
memcpy()s the contents of display targets to the framebuffer device for
displaying.
|
|
|
|
|
|
|
|
|
|
This was missed in commit e7f0f6bb72c63fd6e6ddcb7a815be68682f1764c.
Fixes i915g SCons build.
|
|
|
|
|
|
The xorg state tracker gets two new options to let the user choose
whether to enable / disable dirty throttling and swapbuffer throttling.
The default value of these options are enabled, unless the winsys
supplies a customizer with other values. The customizer record has been
extended to allow this, and also to set winsys-based throttling on a per-
context basis.
The vmware part of this patch disables the dirty throttling if the kernel
supports command submission throttling, and also in that case sets kernel
based throttling for everything but swapbuffers. The vmware winsys does not
set throttling per context, even if it theoretically could, but instead
sets throttling per screen. This should perhaps be changed, should the
xorg state tracker start to use multiple rendering contexts. Kernel throttling
is off by default for all new screens/contexts, so the dri state tracker
is not affected.
This significantly improves interactivity of the vmware xorg driver.
Cherry-picked from commit a8f3b3f88acc1f0193fa740e76e9d815f07f32ab
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Jakob Bornecrantz <wallbraker@gmail.com>
|
|
- Wrapped the buffer and texture create/destroy/transfer/... functions
using u_resource, which is then used to implement the resource functions.
- Implemented texture transfers.
I left the buffer and texture transfers separate because one day we'll
need a special codepath for textures.
- Added index_bias to the draw_*elements functions.
- Removed nonexistent *REP and *FOR instructions.
- Some pipe formats have changed channel ordering, so I've removed/fixed
nonexistent ones.
- Added stubs for create/set/destroy sampler views.
- Added a naive implementation of vertex elements state (new CSO).
- Reworked {texture,buffer}_{from,to}_handle.
- Reorganized winsys files, removed dri,egl,python directories.
- Added a new build target dri-r600.
|
|
|
|
|
|
|
|
With the removal of DRI1 support there where no use of this argument,
some drivers didn't even properly check it.
|
