Age | Commit message (Collapse) | Author |
|
This allow external tools to know for which asics a cs
is destinated to.
|
|
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.
|
|
|
|
|
|
|
|
|
|
Udev code is still there just commented out.
|
|
|
|
|
|
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
|
|
|
|
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 e6c136ca7a4c54457b48be1aec2be024b3e4a28d
commit 85fb3e55fdb7af9b5f59c1ec0f15d1950e601b05
commit d1308f4fe7f94aae51ca9f70947aea8e09597f37
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>
|
|
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>
|
|
|
|
|
|
Conflicts:
configure.ac
|
|
|
|
|
|
|
|
- unreference pushbuf objects on channel destruction
Based on Krzysztof Smiechowicz's patch.
|
|
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
|
|
|
|
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>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Don't store the error return in bo_gem->gtt_virtual or else we will
attempt to use that as a valid pointer in future mappings.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
|
|
|
|
|
|
This is needed as change in kernel will lead to ioctl returning
EINTR if they are interrupted.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
This removes the foremost prolific user of mutexes in libdrm_intel.so.
The other uses of the bufmgr_gem->mutex to serial access to individual
bos are currently required by Mesa, and are far less frequent.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[anholt: This chunk looks good...]
Acked-by: Eric Anholt <eric@anholt.net>
|
|
Forgot to update this when pushing the pageflip bits.
|
|
Conflicts:
include/drm/drm.h
|
|
|
|
|
|
Conflicts:
include/drm/drm.h - RMFB had its signature changed to avoid uint32_t
|
|
|
|
|
|
|
|
This has the unfortunate behaviour of releasing our malloc cache, but
the alternative is for X to consume a couple of gigabytes of ram and
die during testing. Fortunately the extra mallocs have little impact on
performance whereas avoiding swap and death, lots.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Instead of forcing the caller to check after every emit_reloc(), we can
flag the object as being in error, propagating that error upwards through
the relocation tree, and failing the eventual batch buffer execution.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|