Age | Commit message (Collapse) | Author |
|
this is just prep work for evergreen VT save/restore
|
|
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=31364 .
|
|
|
|
This lets multi-screen work better, but still having issues after server
recycle, but it doesn't crash at least.
|
|
should fix https://bugs.freedesktop.org/show_bug.cgi?id=29726
the problem is of course the second head instance tries to access the
fd and fails, however I think this might break syncing on the second
head but not sure, but its better than just hanging up the X server
|
|
More duplicated paths discoved...
|
|
Previously there were 3 different paths with what should
have had duplicated code:
- EXACreatePixmap2
- Initial front buffer creation
- Randr resize
This patch attempts to unify the alignment across all 3.
This may fix tiling issues in some cases and should make
buffer pitches match for pageflipping.
|
|
Fixes compile warning due to local variable ppix being unused when building
against current xserver Git.
|
|
|
|
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=31086 .
|
|
Texture coordinates work fine with or without these,
but this should be more correct I think although
I don't think it matters since we aren't sending w
anyway.
|
|
|
|
Save and restore the palettes on VT switch. The restore
has to be done after the vga restore to work properly as
determined by Jonathan Kollasch.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=18407
|
|
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=30330
|
|
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=15391
|
|
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=30451
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
|
|
Otherwise things like xf86MonitorIsHDMI() won't work right.
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
|
|
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Cover all 6 possible crtcs.
|
|
- add mising LVTMA case statement for DCE3.0 dig encoder
- some DCE4 systems have EN/DISABLE_OUTPUT actions
|
|
- Header size was already subtraced from table size
- Only hw capable ddc pads are shared with aux
|
|
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=30686
|
|
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=30685
|
|
Properly handle asynchronous DRI2 events for disconnected clients.
Track client's pending requests and mark them as invalid when the
client disconnects.
This is based on the version from Alban Browaeys in bug #29065.
v1 (Alban Browaeys): Based upon a detailed explanation from Oldřich
Jedlička and comments from Christopher James Halse Rogers.
on http://lists.x.org/archives/xorg-driver-ati/2010-August/016780.html .
v2: Updated version to apply on master. Removed unnecessary
client_index field from _DRI2FrameEvent. Added freeing/removing from
list to failed paths of radeon_dri2_schedule_wait_msc and
radeon_dri2_schedule_swap.
v3: Adopt to older xorg-server that doesn't have dixRegisterPrivateKey.
v4: Conditional include of list.h, unreachable return removed.
v5: Distribute list.h as xorg_list.h, remove xorg-server version check.
Use the version from xorg-server when available (checked in
configure.ac).
v6: Removed xorg_list.h, made DRI2 scheduling features dependent on
list.h presence.
|
|
|
|
|
|
git+ssh://git.freedesktop.org/git/xorg/driver/xf86-video-ati
|
|
evergreen uses separate allocations for depth and stencil,
so to handle that, create a depth buffer large enough to
handle both. This is required for using the stencil
buffer in mesa.
|
|
If the fbLocation was at an address >32 bits, we'd fail.
Change fbLocation to uint64_t and properly cast when needed.
|
|
This fails for MC addresses >32 bits
|
|
On the Alpha architecture unaligned 32bit accesses incur a software
trap to the kernel and pollute the kernel logs. Fixed by use of the
ldl_u() interface.
Signed-off-by: Michael Cree <mcree@orcon.net.nz>
|
|
Fixes deprecation warnings missed out by
f7a91ece264af9f3fd2fc18e99aefcda93ce9f5c
|
|
This avoids costly CPU VRAM reads and lets EXA manage a system memory cache
of the portions of pixmaps needed for unaccelerated operations.
https://bugs.freedesktop.org/show_bug.cgi?id=27139
|
|
Turns on the big-endian paths even for little-endian systems, and adds
similar paths to the r6xx/r7xx functions.
This makes UTS and DFS reliable, which will let PrepareAccess (with
mixed pixmaps) choose to fail based on whether the pixmap is in VRAM
(to avoid CPU reads).
|
|
On big endian systems, PrepareAccess will fail when byte-swapping is
required so UploadToScreen and DownloadFromScreen cannot rely on
fallback to PrepareAccess.
When scratch BO space allocation fails, this patch merely adds simple
fallback to direct CPU access without any GPU blit. This sometimes
requires a CS flush even in UploadToScreen.
(No allocation retry after a flush is added here.)
|
|
If unflushed CS operations write to the pixmap BO, then these need to be
flushed before mapping the BO for read. This currently only affects big
endian systems and only when the operation writes to the GTT domain.
|
|
This is actually only necessary when PrepareAccess may behave differently on
different calls with the same pixmap, which currently doesn't happen.
However resetting bo_mapped is necessary to let PrepareAccess (with mixed
pixmaps) choose to fail based on whether the pixmap is in VRAM (to avoid CPU
reads).
|
|
radeon_bo_is_busy() may return without setting the domain out-parameter.
If this happens, then download via a scratch GTT BO to avoid CPU VRAM read.
|
|
|
|
interlaced used to work without setting these parameters. Changes
in the xserver seem to require them now.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=29591
|
|
VS const buffer offset was wrong.
fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=29788
|
|
Note, you also need a drm patch to fix the GPU hangs:
drm/radeon/kms/evergreen: fix gpu hangs in userspace accel code
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
some stray - signs
|
|
The 7th entry in a lot of evergreen i2c gpio tables is partially
zeroed. Fix the entry.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Column order is wrong on big endian systems, primarly because of a
bits / bytes mix up with the bpp variable. Fix tested with r100 and
r300, screen depth 16 and 32 with YV12 and YUY2 (overlay, textured video),
RGBA and RGBT (overlay).
Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=29041
Signed-off-by: Heikki Lindholm <holin@iki.fi>
|
|
When a client calls ScheduleSwap we set up a kernel callback when the
relevent vblank event occurs. However, it's possible for the client
to go away between calling ScheduleSwap and the vblank event,
resulting in the buffers being destroyed before they're passed to
radeon_dri2_frame_event_handler.
Add reference-counting to the buffers and take a reference in
radeon_dri2_schedule_swap to ensure the buffers won't be destroyed
before the vblank event is dealt with.
This parallels the approach taken by the Intel DDX in commit
0d2392d44aae95d6b571d98f7ec323cf672a687f.
Fixes: http://bugs.freedesktop.org/show_bug.cgi?id=29065
v2: Don't write completion events to the client if it has quit.
v3: Don't try to unref the NULL buffers from a DRI2_WAITMSC event.
Take a ref in schedule_swap earlier, so the offscreen fallback
doesn't incorrectly destroy the buffers.
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
port of 0be3e95c844247746742805830860ace9f546d99 from intel driver.
Remove explicit batchbuffer submit in DRI2 copyregion
Now that we submit from the flush callback chain, we know we'll always
submit before the client receives the reply or event that blocks it from
rendering the next frame.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
this is a port of 69d65f9184006eac790efcff78a0e425160e95aa from the Intel
driver.
Submit batch buffers from flush callback chain
There are a few cases where the server will flush client output buffers
but our block handler only catches the most common (before going into select
If the server flushes client buffers before we submit our batch buffer,
the client may receive a damage event for rendering that hasn't happened yet
Instead, we can hook into the flush callback chain, which the server will
invoke just before flushing output. This lets us submit batch buffers
before sending out events, preserving ordering.
Fixes 28438: [bisected] incorrect character in gnome-terminal under compiz
https://bugs.freedesktop.org/show_bug.cgi?id=28438
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|