xorg-server includes its own bswap_16, bswap_32 etc macros in
its misc.h. This is transcluded after radeon.h in some files.
If the operating system defines bswap_XX in a way that is
unsuitable for a function name (e.g. on NetBSD), this results
in build failures.
Signed-off-by: Nia Alarie <nia@NetBSD.org>
Part-of: <https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/-/merge_requests/23>
Commit d1d8e3c8d0 causes X server
to fail on startup when GPU acceleration is not working (or is
disabled). The reason is that `radeon_get_pixmap_bo` function
gets called too early (before EXA has been initialized) and
fails with an assert:
#0 __GI_raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x76ab1c6c in __GI_abort () at abort.c:79
#2 0x76ac0b64 in __assert_fail_base (fmt=0x76bfbce4 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7658c80c "key->initialized", file=<optimized out>, line=121,
function=0x7658d040 <__PRETTY_FUNCTION__.10607> "dixGetPrivateAddr") at assert.c:92
#3 0x76ac0c0c in __GI___assert_fail (assertion=0x7658c80c "key->initialized", file=0x7658c9d0 "../include/privates.h", line=121,
function=0x7658d040 <__PRETTY_FUNCTION__.10607> "dixGetPrivateAddr") at assert.c:101
#4 0x76579e6c in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=<optimized out>) at ../include/privates.h:121
#5 0x7657a954 in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=<optimized out>) at exa.c:70
#6 dixGetPrivate (key=<optimized out>, privates=<optimized out>) at ../include/privates.h:136
#7 exaGetPixmapDriverPrivate (pPix=<optimized out>) at exa.c:68
#8 0x7623d460 in radeon_get_pixmap_bo (pPix=0x71c1b8) at radeon.h:804
#9 radeon_get_pixmap_handle (pixmap=0x71c1b8, handle=0x7fa22328) at radeon_bo_helper.c:357
#10 0x76244458 in radeon_pixmap_get_fb (pix=0x71c1b8) at radeon.h:886
#11 drmmode_set_mode_major (crtc=0x691860, mode=0x69191c, rotation=<optimized out>, x=<optimized out>, y=<optimized out>) at drmmode_display.c:918
#12 0x762467e8 in drmmode_set_desired_modes (pScrn=0x67c678, drmmode=<optimized out>, set_hw=1) at drmmode_display.c:3128
#13 0x0047bfa4 in MapWindow (client=0x669ec8, pWin=0x7206c0) at window.c:2722
#14 MapWindow (pWin=0x7206c0, client=0x669ec8) at window.c:2665
#15 0x00449650 in dix_main (argc=3, argv=0x7fa22604, envp=<optimized out>) at main.c:247
#16 0x76ab2198 in __libc_start_main (main=0x42db10 <main>, argc=3, argv=0x7fa22604, init=<optimized out>, fini=0x606434 <__libc_csu_fini>, rtld_fini=0x77229930 <_dl_fini>,
stack_end=0x7fa225e0) at libc-start.c:308
#17 0x0042db80 in __start () at ../sysdeps/mips/start.S:110
Don't call `exaGetPixmapDriverPrivate` if the acceleration (EXA) is not
enabled [yet] to avoid the problem.
Closes: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/188
Closes: https://bugzilla.altlinux.org/show_bug.cgi?id=37539
This can legitimately fail if the pixmap's storage is shared from
another device, e.g. when using PRIME render offloading.
(Ported from amdgpu commit 7d3fef72e0c871e1677e9e544f4cae5e238b5c52)
If get_fb_ptr returns NULL, try again after pixmap_get_handle, it should
work then.
Fixes spurious Present page flipping failures using "normal" pixmaps
which aren't shared with direct rendering clients, e.g. with a
compositor using the RENDER extension.
Bugzilla: https://bugs.freedesktop.org/110417
(Ported from amdgpu commit bf61e6d7ac1a5754b1026d7f80acf25ef622c491)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
We continued using the stale cached handle, causing issues e.g. when
resizing the screen via RandR.
Reported-by: iive on IRC
Acked-by: Alex Deucher <alexander.deucher@amd.com>
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>
Inspired by amdgpu, preparation for the following change. For now, this
is mostly a wrapper around struct radeon_bo, no functional change
intended.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
radeon_scanout_extents_intersect could leave the scanout damage region
in an invalid state, triggering debugging checks in pixman:
*** BUG ***
In pixman_region_append_non_o: The expression r->x1 < r->x2 was false
Set a breakpoint on '_pixman_log_error' to debug
(Ported from amdgpu commit 8af989546907ad9fb491d940e1936d3bfc89276b)
We were clobbering entries in mi's global miSpritePointerFuncs struct,
which cannot work correctly with multiple primary screens. Instead,
assign a pointer to our own wrapper struct to PointPriv->spriteFuncs.
Fixes crashes with multiple primary screens.
Fixes: 1fe8ca7597 ("Keep track of how many SW cursors are visible on
each screen")
Reported-by: Mario Kleiner <mario.kleiner.de@gmail.com>
DRI clients can use depth 32 pixmaps while the screen is depth 24, in
which case page flipping would fail.
Reported-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-and-Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
This allows to en-/disable some functions depending on individual screen
settings.
Prep work for more efficient depth 30 support.
Suggested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
And use this to determine when we cannot use page flipping for DRI
clients. We previously did this based on whether the HW cursor cannot
be used on at least one CRTC, which had at least two issues:
* Even while the HW cursor cannot be used, no SW cursor may actually be
visible (e.g. because all cursors are disabled), in which case we can
use page flipping for DRI clients anyway
* Even while the HW cursor can be used, there may be SW cursors visible
from non-core pointer devices, in which case we cannot use page
flipping for DRI clients anyway
(Ported from amdgpu commit 69e20839bfeb3ee0b0a732d72de0a32d6c5435fc)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Allows tidying up radeon_dirty_src_equals and redisplay_dirty slightly.
(Cherry picked from amdgpu commit 1d65ac395971571094df21ca0408d5972c6b56ec)
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Non GLAMOR builds needs pRADEONEnt so move the USE_GLAMOR define
down to make pRADEONEnt defined in this case.
Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Not doing so resulted in DRI2 page flips not actually changing the FB
being scanned out, showing intermittent flicker of the "back" buffer
rendering.
Bugzilla: https://bugs.freedesktop.org/102643
Fixes: 55e513b978 "Use reference counting for tracking KMS framebuffer
lifetimes"
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>
Preparatory, no functional change intended yet.
Also inline radeon_pixmap_create_fb into radeon_pixmap_get_fb, since
there's only one call-site anymore.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
All callers were already passing in a pixmap.
This allows simplifying the rotated scanout case slightly.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Allows cleaning up the code considerably.
v2:
* Fix "drmWaiVBlank" typo, add blank line for readability (Slava Abramov)
* Rename in/out sequence parameters to "target_seq" and "result_seq",
hopefully that will be clearer.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> # v1
References are held by the pixmaps corresponding to the FBs (so
the same KMS FB can be reused as long as the pixmap exists) and by the
CRTCs scanning out from them (so a KMS FB is only destroyed once it's
not being scanned out anymore, preventing intermittent black screens and
worse issues due to a CRTC turning off when it should be on).
v2:
* Only increase reference count in drmmode_fb_reference if it was sane
before
* Make drmmode_fb_reference's indentation match the rest of
drmmode_display.h
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The root window contents may be undefined before that, so we don't want
to show anything yet.
Fixes a crash on startup with rotation and virtual resolution set in
xorg.conf.
Bugzilla: https://bugs.freedesktop.org/100276
Fixes: cc9d6b7db9 ("Move DPMS check from radeon_scanout_do_update to
radeon_scanout_flip")
(Ported from amdgpu commit 981bac185cfd74ae50dffc28f57cf34623a9595f)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This is the earliest opportunity where the root window contents are
guaranteed to be initialized, and prevents drmmode_set_mode_major from
getting called before drmmode_set_desired_modes via RADEONUnblank ->
drmmode_crtc_dpms. Also, in contrast to the BlockHandler hook, this is
called when running Xorg with -pogo.
Fixes intermittently showing garbage on server startup or after server
reset.
As a bonus, this avoids trouble due to higher layers (e.g. the tigervnc
Xorg module) calling RADEONBlockHandler_oneshot repeatedly even after
we set pScreen->BlockHandler = RADEONBlockHandler_KMS.
v2:
* Drop spaces between XORG_VERSION_NUMERIC arguments
* Call radeon_bo_wait after radeon_cs_flush_indirect
Bugzilla: https://bugs.freedesktop.org/99457
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
Option "TearFree" now sets the default value of the output property.
See the manpage update for details.
TearFree is now enabled by default for outputs using rotation or other
RandR transforms, and for RandR 1.4 slave outputs.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This commit replaces the inline assembler code (for x86 platforms) and
loop (for non-x86 platforms) in RADEONLog2 with a one-liner version
based on clz (count leading zeroes).
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Fixes various potential issues with TearFree enabled, e.g. outputs
freezing after display configuration changes.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This will hopefully decrease the chance of accidentally breaking the
build against xserver < 1.13 in the future.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
1.10.0 was released in February 2011.
We've been accidentally requiring 1.10 or newer since 121a6de72d ("Keep
track of damage event related flushes per-client v2").
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
It was only added in xserver 1.15. Fixes build against older xserver.
Reported-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This further reduces the compositing slowdown due to flushing overhead,
by only flushing when the X server actually sends XDamageNotify events
to a client, and there hasn't been a flush yet in the meantime.
v2: Use ScreenPrivateKey, fixes invalid memory access with GPU screens
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
We only need to flush for XDamageNotify events.
Significantly reduces compositing slowdown due to flushing overhead, in
particular with glamor.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
