This commit encompasses the changes necessary to run on top of the 0.0.16
nouveau interface, additional APIs to support the new features of the
interface, as well as code from Luca Barbieri to improve the pushbuf
interface, which just happens to break nouveau's libdrm ABI so was delayed
until now.
API changes as a result of 0.0.16 DRM interface:
1. No more bo_pin()/bo_unpin(), these were only there for UMS and we no
longer support it.
2. Any random nouveau_bo can be submitted to the GPU as a push buffer.
3. Relocations can be applied on any nouveau_bo
This patch changes the pushbuffer ABI to:
1. No longer use/expose nouveau_pushbuffer. Everything is directly
in nouveau_channel. This saves the extra "pushbuf" pointer dereference.
2. Use cur/end pointers instead of tracking the remaining size.
Pushing data now only needs to alter cur and not both cur and remaining.
The goal is to make the *_RING macros faster and make the interface simpler
and cleaner in the process.
The *_RING APIs are unchanged, but those are inlined and the ABI is changed.
Also, anything accessing pushbuf->remaining instead of using AVAIL_RING
will need to be fixed.
The SET_TILING is pernicious in that it overwrites the input arguments
following an error in order to report the current tiling state of the
buffer. This caught us by surprise as we then fed those arguments back
into to the ioctl unmodified following an EINTR and so the kernel then
reported success for the no-op. We interpreted this success as meaning
that the tiling on the buffer had changed so updated our state and
started using the buffer incorrectly in the new tiled/untiled manner.
This lead to all sorts of random corruption and GPU hangs, even though
the batch buffers would look sane (when the GPU had not wandered off
into forbidden territory).
References:
Bug 25475 - [i915] Xorg crash / Execbuf while wedged
http://bugs.freedesktop.org/show_bug.cgi?id=25475
Bug 25554 - i830_uxa_prepare_access: gtt bo map failed: Input/output error
http://bugs.freedesktop.org/show_bug.cgi?id=25554
(And probably every other weird bug in the last few months.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the kernel reports the total number of fences, we must guess how many
fences are likely to be pinned. In the typical system these will be only
used by the scanout buffers, of which there may be one per pipe, and any
number of manually pinned fenced buffers. So take a conservative guess
and reserve two fences for use by the system.
Note this reduces the number of fences to 3 for i915 and prior.
Reference:
http://bugs.freedesktop.org/show_bug.cgi?id=25911
The latest intel driver 2.10.0 causes kernel oops and system hangs
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If there is section size mismatch reusing the section object
makes section start fail.
Reseting the object before doing error checking prevents the
possible flood of errors.
List of changes:
Fixes the cursor size to 64x64, you still need ti supply width and height
Explicitly make the cursor format A8R8G8B8
Explicitly make the scanout format X8R8G8B8
We don't intend libdrm-radeon to become clever enough to
decode cs for all GPU we support. Better to let an external
tool do the job. This will print raw cs in an easy to parse
way.
If the available modes changes between the two GETCONNECTOR ioctls, that
caused the kernel to skip filling one array and led to a crash (as the size
of the allocated and initialised block of memory differed from the reported
size, and might be NULL if no modes were present at first).
This bug manifest its self on my machine due to spurious false positive
detections of a connected TV-out.
Fixes: http://bugs.freedesktop.org/show_bug.cgi?id=25912
Crash whilst probing modes
Based upon the similar fixes for the GETRESOURCES ioctls by Chris Wilson,
in the following commits:
commit e6c136ca7a
commit 85fb3e55fd
commit d1308f4fe7
Signed-off-by: Peter Clifton <pcjc2@cam.ac.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the count is 0, then the malloc is permitted to return NULL, so don't
throw an error in that case.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Peter Clifton hit an issue whereby he had a spurious TV hotplug event
that occurred between the two GETRESOURCES ioctls that caused the kernel
to skip filling one array and led to a crash (as the size of the
allocated and initialised block of memory differed from the reported
size).
Fixes: http://bugs.freedesktop.org/show_bug.cgi?id=25912
Crash whilst probing modes
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Peter Clifton <pcjc2@cam.ac.uk>
as Michel pointed out we are exposing too much info for these object
for this to be maintainable going forward.
This patch set minimises the exposed parts of the radeon_bo and
radeon_cs objects to the piece necessary for ddx/mesa to operate
at a decent speed.
The major problem is mesa contains a legacy BO/CS managers which we still
need to expose functionality to, and we really cannot change the API
until we can drop the non-KMS codepaths.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Luca Barbieri
Alex Deucher
Chris Wilson
Matthew W. S. Bell
Pauli Nieminen
Dave Airlie
Francisco Jerez
Marcin Slusarz
Jakob Bornecrantz
Marcin Kościelnicki
Ben Skeggs
Alan Coopersmith
Jerome Glisse
Peter Clifton
Younes Manton