Age | Commit message (Collapse) | Author |
|
The compat header takes care of the old server vs new server.
this commit was autogenerated from util/modular/x-driver-screen-scrn-conv.sh
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Due to some old kernel issue, height is 8 aligned insided the ddx
For buffer with height btw 57 & 63 this lead ddx to believe it can
allocate a 2D tiled surface while mesa will not align height and
will assume 1D tiled leading to disagreement and rendering issue.
This patch force buffer with height < 64 to be 1D tiled.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Use libdrm common surface code so mesa,ddx have same idea
about tiling surface and what their pitch should be and
the alignment constraint.
v2 fix remaining issue add new option to conditionaly enable
v3 fix fbcon copy and r600 exa copy path
v4 fix non tiled path 2D tiling on GPU >= R600, set it to false
as default
v5 adapt to pixel/element size split of libdrm/radeon
v6 update to properly handle falling back to 1d tiled
v6 final fix to tile split value on evergreen and newer
v7 fix default array mode on r6xx, fix height alignment issue
on evergreen
v8 fix tile split value
v9 add stencil tile split support, simplify dri2 for stencil
with evergreen
v10 Try to fix xv path regarding tiling. Adapt to libdrm API
change. Try to fix case where there is no surface which
means non tiled bo.
v11 check for proper libdrm
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
So it appears the M7 family always tiles its depth buffer also.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
When we do the allocations we need to make sure the always tiled
nature is taken into account.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This avoids calling into the kernel for each bo in the accel
code. This is a follow on to:
cc7d1fa39da40a532fcdbe6c7924ca47a879e66a
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Calling into the kernel every time is quite expensive, and nobody else should
ever change the tiling flags.
There's still more to do along the same lines for >= R6xx.
|
|
this corrects the function name so it matches the contents.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This caused a regression in firefox, as these numbers are xFixed
values hence 1 is actually 65536.
Should fix: https://bugzilla.redhat.com/show_bug.cgi?id=685084
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
rendercheck tsrccoords test fails.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Use UTS/DFS to tile/untile as appropriate for sw access on
pre-6xx.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=33738
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
git+ssh://git.freedesktop.org/git/xorg/driver/xf86-video-ati
|
|
We need to implement a texture lookup with perspective
divide for non-affine transforms. For now just fallback.
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=31799
although it appears either EXA or the xserver gets this
wrong too.
|
|
Use UTS/DFS to tile/untile as appropriate for sw access.
Also enables pageflipping with tiling enabled.
|
|
On r6xx+, 2D tiling can require larger than 4k base alignment.
|
|
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.
|
|
|
|
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
|
|
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).
|
|
Requires radeon drm 2.6.0 and updated mesa.
v2: - fix lockup due to not emiting DB_DEPTH_INFO
https://bugs.freedesktop.org/show_bug.cgi?id=28342
- fix drm minor version to deal with evergreen accel
v3: rebase on current ddx git
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
This is a precursor for r300/500 vbo support.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Fixes deprecation warnings with xserver master and should also work with older
xservers.
|
|
Signed-off-by: Marek Olšák <maraeo@gmail.com>
|
|
Pixmaps smaller than a macrotile cannot be used as textures because hardware
automatically switches to macro-linear and therefore sampled pixels are
messed up. This behavior is known as MACRO_SWITCH.
The only sane workaround seems to be not using macrotiling for small pixmaps.
The function RADEONMacroSwitch has been ported from r300g and implements
MACRO_SWITCH the same way it's implemented in hardware. It's been well tested
in r300g.
This commit also fixes blit-based framebuffer reads, which are used for tiled
surfaces in r300g, when ColorTiling is enabled.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
|
|
Also fix some RADEON_ALIGN(x, 63), which would return incorrect results
for odd x. Though this shouldn't happen, it's still not right. You
wouldn't ever write (x + 62) & ~62 which is clearly wrong (and what it
expands to).
CC: Jerome Glisse <jglisse@redhat.com>
CC: Alex Deucher <alexdeucher@gmail.com>
CC: Dave Airlie <airlied@redhat.com>
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
Also, define RADEON_BUFFER_ALIGN in terms of it, and replace some
RADEON_ALIGN(x, RADEON_BUFFER_ALIGN) with RADEON_ALIGN(x,
RADEON_GPU_PAGE_SIZE) since this is really what was intended.
CC: Jerome Glisse <jglisse@redhat.com>
CC: Alex Deucher <alexdeucher@gmail.com>
CC: Dave Airlie <airlied@redhat.com>
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
Use the Xv version as it takes into account the area
covered by the op rather than just picking the largest
crtc area.
|
|
|
|
This moves to a boolean instead of using VRAM sizing.
as per Michel's suggestions on list.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
This patch returns NULL for pixmap creation when we are using
mixed pixmaps and the pixmap has a size.
The size check is necessary for the front buffer.
We add a flag to force pixmap creation for certain pixmaps
that need to be hw, like the DRI2 and Xv ones.
Idea from Michel and workarounds from Ben Skeggs.
v2: add Option "EXALowVRAM" to allow configuring this, value in MBs.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Requires at least xserver 1.7 to work properly.
Also make sure the front buffer is and stays tiled if colour tiling is enabled.
|
|
drm crtc ids do not correspond to actual hw crtcs,
as such the vline stuff was never enabled for Xv.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
|
|
libdrm_radeon always takes care of this implicitly now.
|
|
This is the intention with EXA in xserver Git, and IME it improves performance
significantly even with older versions.
|
|
Adapted from various patches from Dave and Jerome.
|
|
allow the first use to decide placement.
|
|
This requires an X server from git with createpixmap2 support fixed up in it.
On 1.6 and previous it won't do any tiling, if you are running git server
please upgrade to latest git.
Option "AllowColorTiling" "true" to enable and do some testing
|
|
Without this, apparently they are initially allocated in system RAM (or
possibly GTT), so any GPU rendering to them first triggers a copy of the whole
uninitialized data to VRAM...
We may want to explore more sophisticated schemes in the future, but for now
this seems to improve KMS 2D performance quite a bit.
|
|
Only compile tested.
|
|
This uses a new libdrm interface which shares code with mesa.
It also fixes the bo to flush when full instead of never flushing.
It survives gtkperf -a here which the driver didn't before now
|
|
|
|
|
|
This adds DRI2 + KMS + driver pixmaps support to the driver.
I've decided to just do a completely separate KMS driver file
instead of hacking the crap out of radeon_driver.c. So now
I do the KMS check in radeon_probe.c time and set the DDX
pointed up to a completely different set at this stage.
This avoids a lot of if (kms) type crap in the code at
the expense of making sure we make changes to both files
if necessary.
This code is still disabled in configure.ac as I broke EXA composite
rendering somehow in KMS mode
|
|
This patch contains most of the changes to the EXA and texture video
accel code.
It adds a few bits of pixmap support but doesn't actually do anything
useful KMS yet.
Testing this should not have any regressions over what we have already,
biggest worries are r6xx, I've fixed a textured video one, but no idea
what other might lurk
It won't build against libdrm radeon yet either
|
|
And signal this to the EXA core using the new EXA_SUPPORTS_PREPARE_AUX flag.
|
|
This reverts commit de358736dc696559ba99c71cf5b2a97508201630.
|
|
git+ssh://agd5f@git.freedesktop.org/git/xorg/driver/xf86-video-ati
|