I went a step too far... I still need some define in order to switch
between uxa/sna at compile time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
DRI2 presumes that the pixmap->serialNumber can be used as unique id.
If it changes revokes *all* the buffers, it presumes a new pixmap has
been attached to the window, for example after a reconfiguration event
(resizing of a window, or a mode switch). However, as we updated the
root pixmap upon a pageflip, we were triggering revocations everytime,
causing further revocations and massive aperture thrashing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the introduction of the unrolled fill_boxes() was bypassing the
effective optimisation in fill_one().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By working around the broken shaders, we emitted the CA rectangle in the
middle of a sequence of glyphs and left the state setup for CA. So we
need to reset the pipeline state at the start of every composite blt.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Clip the operation extents before passing to the backend to setup the
operation, so that we only need to upload the minimum amount of data
necessary, or avoid tiling etc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can write into the bo if it has no outstanding requests, whereas we
were checking to see it was last on the gpu instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order that we remember to flush the contents back to the GPU
before we wake up the DRI clients, we need to add those dirty
pixmaps to the flushing list. I caught the obvious place, the
central move-to-cpu, but I missed a couple of paths were we
optimise the copy onto the shadow.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we will immediately attempt to replace it with an inactive when
moving the data to the GPU, short-circuit that replacement.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These only existed to work around an include order problem, when kgem
was intended to be entirely separable from sna. Moving the function
pointer into kgem simplifies matters.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we check for retirement everytime we wakeup, it is seldom useful to
check again until we know we have invoked an operation that may block.
But when we do check, we do not want to scan the entire active list
looking for flushing candidates, so track those on a separate list.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So that we can simply query it from each of the Zaphod instances without
blocking. Requires a fixed kernel...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And bump configure.ac to require dri2proto >= 2.6, because
DRI2BufferStencil and DRI2BufferHiz were introduced in that version.
When a client requests DRI2BufferHiz or DRI2BufferStencil,
I830DRI2CreateBuffer() now returns a Y-tiled buffer. The stencil buffer is
handled as a special case due its quirky pitch requirements.
CC: Eric Anholt <eric@anholt.net>
CC: Ian Romanick <idr@freedesktop.org>
CC: Kristian Høgsberg <krh@bitplanet.net
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad@chad-versace.us>
Before this commit, if a client were to request an unrecognized DRI2
buffer, such as DRI2BufferStencil, then I830DRI2CreateBuffer() allocated
and returned an X-tiled buffer by accident. The problem was that
unrecognized tokens were caught by the default case of a switch statement.
Now, when given unrecognized DRI2 tokens, I830DRI2CreateBuffers() returns
null.
This shouldn't break older Mesa versions, because they never query (via
DRI2GetBuffersWithFormat) for the drawable's DRI2BufferStencil.
CC: Eric Anholt <eric@anholt.net>
CC: Ian Romanick <idr@freedesktop.org>
CC: Kenneth Graunke <kenneth@whitecape.org>
CC: Kristian Høgsberg <krh@bitplanet.net
Signed-off-by: Chad Versace <chad@chad-versace.us>
A left-over from before the surface was embedded into the tail of the
batch, we were only checking for room against the total size of the
batch buffer. So under the wrong set of circumstances we ended up
overwriting surface data with batch and triggering a GPU hang on gen4+.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Zaphod support is a rudimentary method for creating an Xserver with
multiple screens from a single device. The Device is instantiated, with
a duplication of its resources, as many as required up to a maximum of
the number of its outputs, and each instance is attached to a Screen
and added to the ServerLayout. A Device can be bound to a selection of
outputs using a comma separated list of RandR names.
Note: in general, this is not the preferred solution! And will be
superseded by per-crtc-pixmaps in RandR-1.4.
For example, the following xorg.conf fragment creates an XServer with
two screens, one attached to the LVDS panel on the laptop, and the other
to any external output:
Section "Device"
Identifier "Intel0"
Driver "intel"
BusID "PCI:0:2:0"
Option "ZaphodHeads" "LVDS1"
Screen 0
EndSection
Section "Device"
Identifier "Intel1"
Driver "intel"
BusID "PCI:0:2:0"
Option "ZaphodHeads" "DVI1,VGA1"
Screen 1
EndSection
Section "Screen"
Identifier "Screen0"
Device "Intel0"
EndSection
Section "Screen"
Identifier "Screen1"
Device "Intel1"
EndSection
Section "ServerLayout"
Identifier "default"
Screen "Screen0"
Screen "Screen1"
EndSection
Based on a patch by Ben Skegs <bskeggs@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
830/845 cannot directly sample from an x8r8g8b8 source, but if we know
that we are only sampling from within the confines of the source then we
force the alpha channel to one. (Outside of the source we require the
sampler to return a==0.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Valgrind detected that I missed initialised a couple of fields for
use with the generic state emission paths:
==28683== Conditional jump or move depends on uninitialised value(s)
==28683== at 0x83BE646: gen6_get_blend (gen6_render.c:251)
==28683== by 0x83BF769: gen6_emit_state (gen6_render.c:818)
==28683== by 0x83C38ED: gen6_emit_copy_state (gen6_render.c:2280)
==28683== by 0x83C3C89: gen6_render_copy_boxes (gen6_render.c:2356)
==28683== Conditional jump or move depends on uninitialised value(s)
==28683== at 0x83C15C3: gen6_rectangle_begin (gen6_render.c:1458)
==28683== by 0x83C177D: gen6_get_rectangles (gen6_render.c:1502)
==28683== by 0x83C3D16: gen6_render_copy_boxes (gen6_render.c:2363)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... and so avoid having to move it the GPU, as seen in the wild. It
looks like I will actually need to handle mixed Render/Core operations
on the frontbuffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We were always terminating the batch with the non-pipelined op, and not
just at the end of a BLT sequence.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Chad Versace