We either conflated bpp (which fails given a mixture of depth-24 and
depth-30 pixmaps) or neglected to check at all.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It is to prepare for Xv on Ivybridge. The difference from Sandybridge
is that all message payload must be in GRF registers instead of MRF registers
on Ivybridge. We will only redefine some M4 macros for Ivybridge
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
Fixes a regression from d0362a. In bypassing the is_wedged checked, we
also ended up bypassing the checks that we could indeed render to the
target bo. With the result that we were creating GPU buffers for SHM
surfaces, something that requires Xserver fixes before we can actually
enable...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
...both to correct the placement of the fbcon into the smaller scanout and
to ensure that we correctly clip the boxes to be copied.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So in order not to block server shutdown, check that the fd is readable
before attempting to read from it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise if we fail to check, then we create a 0x0 surface to sample
with the operation -- net result is that we end up using a clear source
instead of the desired mask.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I'd like it to not be in the SDK anymore, and we're not using anything
from it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise we end up doing work for no reason, ala the regression in
grads-heat-map. However, it is important that the damage is reduced at
some point or else it may grow unbounded. Hopefully normal usage will
never hit the pathologocial case...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For the broken shader workaround, we need to reset the pipeline state
before every blt as the state is changed by the magic CA pass. So we
need to check that we actually have sufficient space to emit the
pipelined pointers before doing so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to attach a scanout (and use swrast) on a wedged GPU, we need to
bypass the safety checks for normal pixmap creation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This patch has been carried by the distributions every since they
started doing graphical boot splashes. Time to integrate it and give it
some TLC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We only use it for the id. Everything else stored on it, like the
buffer_id, is not permanent and we need to query the current status as
required.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
BOX_EMPTY(&box) surprisingly compiles and generates interesting code that
evaluates to if (0). Oops.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We only want to process retirements if we know we caused a stall waiting
for the GPU to release the bo before performing IO.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A pox on all those who write trivial patches, attempt to compile on a
system not having dri2proto and just assume that all is good.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
pixman complains if you attempt to use a region created with an invalid
box, so don't do that.
Reported-by: Reinhard Karcher <reinhard.karcher@gmx.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since we have no global resource allocator for zaphod mode, that's what
RandR-1.4 solves, we have to further constrain zaphod mode to only use
one crtc per screen. This also means that you must match the output
restrictions within the Screen definitions, noting that the crtc pipe id
corresponds with the screen number.
Reportede-by: Phillp Haddad <phillip.haddad@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By not tracking the front buffer correctly, i.e. performing the exchange
on every swap, GL_FRONT was no longer pointing at the updated buffer and
neither was the root pixmap. So both X and GL would read the wrong
buffer was the flip was pending.
The other issue was that we would feed the old front buffer back to the
application as a future back buffer (due to buffer caching) and so the
kernel would duly insert a WAIT_EVENT for the pending flip to complete
before allowing rendering to affect it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the client exits before the async page-flip completes then we still
need to decrement the pending flip count in order to correctly flip the
scanout next time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Before the xserver is patched to send notification of release of the
scratch pixmaps, we cannot associated GPU resources with them. In
practice, the only advantage for doing so is for SHM pixmaps...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Xiang, Haihao
Adam Jackson