Age | Commit message (Collapse) | Author |
|
I missed this before because this code isn't compiled with current
xserver.
Trivial.
|
|
Inspired by amdgpu. This avoids various issues due to a GEM handle
lifetime conflict between us and Mesa with current glamor.
Bugzilla: https://bugs.freedesktop.org/105381
Tested-by: Konstantin Kharlamov <hi-angel@yandex.ru>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
xserver 1.13.0 was released on September 6th, 2012, almost 5 years ago.
This allows cleaning up a bunch of backwards compatibility code.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
So it can be used outside of the DRI2 code.
(Ported from amdgpu commit 5518bf5d793439b5bab369e5fc18de9a4a3b9dd6)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Reviewed-by: Dave Airlie <airlied@redhat.com>
|
|
There is already a radeon_pixmap forward decl here, the #else
block is missing one.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
When this option is enabled, most pixmaps (including the screen pixmap)
are allocated in system RAM and mostly accessed by the CPU. Changed areas
of the screen pixmap are copied to dedicated per-CRTC scanout pixmaps
regularly, triggered by the vblank interrupt.
v2:
* Set region data pointer to NULL for keeping only the extents
* Move pRegion and pBox local variable declarations closer to their uses
in drmmode_set_mode_major()
|
|
They can choose between using the GPU or CPU for the operation.
|
|
|
|
|
|
The behaviour is the same as when the removed flags were passed in.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
We can't create our own struct radeon_bo representation in this case
because destroying that would make the GEM handle inaccessible to glamor
as well. So just get the handle directly via dma-buf.
v2: Close dma-buf file descriptor, pointed out by Axel Davy.
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
|
|
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
I need to stop pushing patches first thing in the morning.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This creates adaptors using glamor if possible.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Otherwise rotation won't work when glamor support isn't built in.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Defaults to shadowfb. 3D acceleration is available with glamor. 2D
acceleration is disabled until the radeonsi driver can handle glamor's
shaders.
v2: add chip flags (Alex Deucher)
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Enable at build time with --enable-glamor and runtime with
Option "AccelMethod" "glamor"
The most notable lack of functionality is XVideo. Use something like VDPAU for
now.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
|