drm/radeon: using libdrm_radeon for a new display server

On Mon, Mar 28, 2011 at 9:35 AM, Chia-I Wu wrote: > Hi list, > > I have a simple scenario that there are clients rendering to buffer > objects using the CPU, and the display server compositing the buffers > using OpenGL and doing page flips to present the final contents. It > is like doing the f

[PATCH] drm/radeon/kms: add missing Evergreen texture formats to the CS parser

BC6 and BC7 are described in ARB_texture_compression_bptc. No idea what FMT_32_AS_32_32_32_32 is good for. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/r600_cs.c | 28 ++-- drivers/gpu/drm/radeon/r600d.h |3 +++ 2 files changed, 21 insertions(+), 10 dele

[PATCH] drm/radeon/kms: add a CS ioctl flag not to rewrite tiling flags in the CS

Ping. Will anyone pick up this patch, please? Marek On Tue, Oct 25, 2011 at 1:38 AM, Marek Ol??k wrote: > This adds a new optional chunk to the CS ioctl that specifies optional flags > to the CS parser. Why this is useful is explained below. Note that some regs > no longer need the NOP relocatio

R600g ported to mesa git

Hi Jerome, I've ported your R600 Gallium3D driver to current mesa git. The list of changes: - Wrapped the buffer and texture create/destroy/transfer/... functions using u_resource, which is then used to implement the resource functions. - Implemented texture transfers. I left the buffer and textu

Re: [PATCH] drm/radeon: signal all fences after lockup to avoid endless waiting in GEM_WAIT

ake GPU resets more reliable I would rather suggest to remove > the ring lock dependency. > Then we should try to give all the fence wait functions a (reliable) timeout > and move reset handling a layer up into the ioctl functions. But for this you > need to rip out the old PM code firs

Re: [PATCH] drm/radeon: signal all fences after lockup to avoid endless waiting in GEM_WAIT

tion? >> >> I'm pretty sure that we nearly always have a problem when two threads are >> waiting for fences on one of them detects that we have a lockup while the >> other one keeps holding the exclusive lock. Signaling all fences might work >> around that problem, b

Re: [PATCH] drm/radeon: signal all fences after lockup to avoid endless waiting in GEM_WAIT

tian König wrote: > Mhm, that doesn't looks like anything related but more like the reset of the > compute ring didn't worked. > > How often does that happen? And do you still get the problem where X waits > for a fence that never comes back? > > Christian. >

Re: [PATCH 1/2] drm/radeon: stop the leaks in cik_ib_test

I tested this and had over 1546 lockups followed by a successful GPU reset. Then the kernel probably crashed (judging by the fact ssh was dead). Still, it's pretty impressive. There is a new problem though. The X server sometimes gets stuck in GEM_WAIT and waits forever, even if there were no lock

Re: [PATCH 1/2] drm/radeon: stop the leaks in cik_ib_test

Ooops, the new problem is not so rare. It has now happened to me 3 times in an hour. Marek On Mon, Oct 14, 2013 at 9:13 PM, Marek Olšák wrote: > I tested this and had over 1546 lockups followed by a successful GPU > reset. Then the kernel probably crashed (judging by the fact ssh was

Re: [PATCH 1/2] drm/radeon: stop the leaks in cik_ib_test

ard to say what's going wrong this time, but we probably need to fix it > before the final release. > > Do you have a kernel backtrace from the lockups? Or at least some way to > reproduce it? > > Christian. > > Am 14.10.2013 21:34, schrieb Marek Olšák: > >> Ooop

[PATCH 0/2] drm/radeon/kms: tex3D mipmap fix & R500 VAP regs

Hi devs, The first attached patch fixes the calculation of mipmapped 3D texture sizes in the CS checker, the 3rd dimension (depth) should be minified too. This should probably go to 2.6.34. The second patch adds 2 new regs: - VAP_ALT_NUM_VERTICES, along with an update to the CS checker. - VAP_IND

[PATCH 0/2] drm/radeon/kms: tex3D mipmap fix & R500 VAP regs

On Sun, Apr 11, 2010 at 8:12 PM, Jerome Glisse wrote: > On Sun, Apr 11, 2010 at 06:39:05AM +0200, Marek Ol??k wrote: > > Hi devs, > > > > The first attached patch fixes the calculation of mipmapped 3D texture > sizes > > in the CS checker, the 3rd dimension (depth) should be minified too. This > >

[PATCH] drm/radeon/kms: r300 fix CS checker to allow zbuffer-only fastfill

Please review. -- next part -- An HTML attachment was scrubbed... URL: -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-kms-r300

[PATCH] drm/radeon: add a way to revoke hyper-z access

Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/radeon_kms.c | 24 +++- 1 files changed, 19 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c index ddcd3b1..0e5deea 100644 --- a/drivers/gpu/drm/radeon

[PATCH] drm/radeon/kms: allow FG_ALPHA_VALUE on r5xx

This is a CS checker fix. I need this for FP16 alpha-test. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/reg_srcs/rv515 |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/reg_srcs/rv515 b/drivers/gpu/drm/radeon/reg_srcs/rv515 index 8293855..b

[PATCH] drm/radeon/kms: allow r500 US_FORMAT regs in the CS checker

And bump the DRM version to 2.8.0. The purpose of these regs is to work around a TX hw bug in R520. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/radeon_drv.c |5 +++-- drivers/gpu/drm/radeon/reg_srcs/rv515 | 16 2 files changed, 19 insertions(+), 2 deletions(-)

[PATCH] drm/radeon/kms: add ARGB2101010 colorbuffer support for r500

This should be part of DRM 2.8.0. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/r300.c |7 +++ drivers/gpu/drm/radeon/radeon_drv.c |2 +- 2 files changed, 8 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c index c

[PATCH] drm/radeon/kms: optimize CS state checking for r100->r500

The colorbuffer, zbuffer, and texture states are checked only once when they get changed. This improves performance in the apps which emit lots of draw packets and few state changes. This drops performance in glxgears by a 1% or so, but glxgears is not a benchmark we care about. The time spent in

[PATCH] drm/radeon/kms: optimize CS state checking for r100->r500

On Sat, Feb 12, 2011 at 7:21 PM, Marek Ol??k wrote: > The colorbuffer, zbuffer, and texture states are checked only once when > they get changed. This improves performance in the apps which emit > lots of draw packets and few state changes. > > This drops performance in glxgears by a 1% or so, bu

[PATCH 1/2] drm/radeon/kms: fix tracking of BLENDCNTL, COLOR_CHANNEL_MASK, and GB_Z on r300

Also move ZB_DEPTHCLEARVALUE to the list of safe regs. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/r300.c |3 +-- drivers/gpu/drm/radeon/reg_srcs/r300 |3 +-- drivers/gpu/drm/radeon/reg_srcs/r420 |4 +--- drivers/gpu/drm/radeon/reg_srcs/rs600 |3 +-- drivers/g

[PATCH 2/2] drm/radeon/kms: check AA resolve registers on r300

This is an important security fix because we allowed arbitrary values to be passed to AARESOLVE_OFFSET. This also puts the right buffer address in the register. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/r100.c | 25 + drivers/gpu/drm/radeon/r100_trac

[PATCH] drm/radeon/kms: do not reject X16 and Y16X16 floating-point formats on r300

Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/r300.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c index 768c60e..069efa8 100644 --- a/drivers/gpu/drm/radeon/r300.c +++ b/drivers/gpu/drm/radeon/r300.

[PATCH] drm/radeon/kms: manage r300 CMASK RAM access and allow CMASK clear

The CMASK RAM is for colorbuffer compression (used in conjunction with MSAA). Only one user (filp) can access it. The CMASK RAM access is managed in the same way as Hyper-Z, but there is a separate ioctl, because an app that uses MSAA does not necessarily have to use zbuffering. Signed-off-by: Ma

[PATCH] drm/radeon/kms: release CMASK access in preclose_kms

Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/radeon_kms.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c index 28a53e4..a794e17 100644 --- a/drivers/gpu/drm/radeon/radeon_kms.c +++ b/dri

[PATCH] drm/radeon/kms: do bounds checking for 3D_LOAD_VBPNTR and bump array limit

To my knowledge, the limit is 16 on r300. (the docs don't say what the limit is) The lack of bounds checking can be abused to do all sorts of things (from bypassing parts of the CS checker to crashing the kernel). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36745 Cc: stable at kernel.

[PATCH 4/6] drm/radeon: add buffers to the LRU list from smallest to largest

Only the VMWare driver uses ttm_eu_fence_buffer_objects. Cc'ing Thomas. What do you think about this, Thomas? Marek On Thu, Feb 27, 2014 at 2:22 AM, Michel D?nzer wrote: > On Mit, 2014-02-26 at 19:25 +0100, Marek Ol??k wrote: >> >> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c >> b/drivers/gp

[PATCH 1/6] drm/radeon: add a way to get and set initial buffer domains

From: Marek Ol??k When passing buffers between processes, the receiving process needs to know the original buffer domain, so that it doesn't accidentally move the buffer. v2: reserve the buffer Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/radeon.h| 3 +++ drivers/gpu/drm/rad

[PATCH 0/6] Radeon memory management improvements v3

While updating "[PATCH 5/6] drm/radeon: validate relocations in the order determined by userspace" based on feedback, which should have been a harmless change, I discovered that the performance dropped. The problem was that list_add/move from one list to another reversed the list of relocations

[PATCH 2/6] drm/radeon: track memory statistics about VRAM and GTT usage and buffer moves

From: Marek Ol??k The statistics are: - VRAM usage in bytes - GTT usage in bytes - number of bytes moved by TTM The last one is actually a counter, so you need to sample it before and after command submission and take the difference. This is useful for finding performance bottlenecks. Userspace

[PATCH 4/6] drm/radeon: add buffers to the LRU list from smallest to largest

From: Marek Ol??k Signed-off-by: Marek Ol??k Reviewed-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_cs.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index f28a8d8..d49a3f7 100644 -

[PATCH 3/6] drm/radeon: deduplicate code in radeon_gem_busy_ioctl

From: Marek Ol??k Signed-off-by: Marek Ol??k Reviewed-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_gem.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index 9863ca7..d09650c

[PATCH 5/6] drm/radeon: validate relocations in the order determined by userspace

From: Marek Ol??k Userspace should set the first 4 bits of drm_radeon_cs_reloc::flags to a number from 0 to 15. The higher the number, the higher the priority, which means a buffer with a higher number will be validated sooner. The old behavior is preserved: Buffers used for write are prioritize

[PATCH 6/6] drm/radeon: limit how much memory TTM can move per IB according to VRAM usage

From: Marek Ol??k Signed-off-by: Marek Ol??k Reviewed-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_cs.c | 2 +- drivers/gpu/drm/radeon/radeon_object.c | 88 +++--- drivers/gpu/drm/radeon/radeon_object.h | 3 +- 3 files changed, 85 insertions(+), 8 del

[PATCH] drm/radeon: set PIPE_CONFIG for 1D and linear tiling modes on CIK

From: Marek Ol??k This fixes fast color clear with 1D-tiled single-sample surfaces and Hyper-Z corruption with 1D-tiled depth surfaces. Even though it seems it is not needed for 1D tiling, CMASK and HTILE are always 2D-tiled, thus the hw needs to know the actual pipe configuration for CMASK and

CIK hangs with kernel 3.15, bisected

Hi Christian, This commit which first appeared in 3.15-rc1 causes hangs on Bonaire: commit 6d2f2944e95e504a7d33385eeeb9bb7fcca72592 Author: Christian K?nig Date: Thu Feb 20 13:42:17 2014 +0100 drm/radeon: use normal BOs for the page tables v4 No need to make it more complicated than

CIK hangs with kernel 3.15, bisected

Hi Christian, I have tested it and it doesn't fix the hangs. (Also, I don't like the patch, because it reverts the behavior I added for userspace buffers.) Marek On Sat, May 10, 2014 at 6:34 PM, Christian K?nig wrote: > Couldn't reproduce the issue so far. So the attached patch is just a > c

CIK hangs with kernel 3.15, bisected

Your latest patches fix the regression. The performance regression can also be reproduced with piglit "-t texelFetch.fs". Kernel 3.14: real0m17.724s user0m41.905s sys0m11.299s The problematic commit checked out + your fixes (without the PTE patch I think): real0m23.47

CIK hangs with kernel 3.15, bisected

I think it's caused by something else. I'll continue testing and bisecting. Marek On Tue, May 13, 2014 at 5:31 PM, Christian K?nig wrote: > Is the performance regression regression caused by the page table changes or > something else? > > I did made some tests with xonotic while developing it an

[PATCH 2/2] drm/radeon: fix buffer placement under memory pressure v2

For the patch: Reviewed-by: Marek Ol??k It would be clearer if alt_domain was renamed to allowed_domains. Marek On Mon, May 12, 2014 at 3:30 PM, Christian K?nig wrote: > From: Christian K?nig > > Some buffers (UVD/VM page tables) must be placed in VRAM, > but the byte restriction for moving

CIK hangs with kernel 3.15, bisected

Hi Christian, The performance regression I saw with piglit seems to be fixed with latest kernel git. It's difficult to bisect the kernel, because there are only merges between 3.14 and 3.15 and the merged committs are actually based on 3.14-rc1 and 3.14-rc4. All seems to be fine with your fixes.

CIK hangs with kernel 3.15, bisected

I applied these two patches Christian sent to dri-devel: drm/radeon: fix page directory update size estimation drm/radeon: fix buffer placement under memory pressure v2 on top of torvalds's master branch. Marek On Tue, May 13, 2014 at 10:19 PM, Grigori Goronzy wrote: > On 13.05.2014 21:50, Mar

CIK hangs with kernel 3.15, bisected

Hi Christian, Even though some regressions are fixed by these patches: drm/radeon: fix page directory update size estimation drm/radeon: fix buffer placement under memory pressure v2 and indeed, the texelFetch tests no longer hang, there is one more hang which needs to be fixed. :( All I know is

[PATCH] radeon: Allow N x 1 x 1 surfaces for evergreen+

I think it would be cleaner to add a new SURF_TYPE for buffers and only allow large npix_x for that (and adding all the necessary sanity checks to disallow invalid values). Also, if you want to use it in Mesa, you or somebody else should: 1) make a libdrm release 2) bump libdrm_radeon version requ

[PATCH] drm/radeon/kms: allow STRMOUT_BASE_UPDATE on RS780 and RS880

This is required to make streamout work there. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/r600_cs.c|3 ++- drivers/gpu/drm/radeon/radeon_drv.c |3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r

[PATCH] drm/radeon: allow MIP_ADDRESS=0 for MSAA textures on Evergreen

MIP_ADDRESS should point to the resolved FMASK for an MSAA texture. Setting MIP_ADDRESS to 0 means the FMASK pointer is invalid (the GPU won't read the memory then). The userspace has to set MIP_ADDRESS to 0 and *not* emit any relocation for it. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/ra

[PATCH] radeon: don't take the stencil-specific codepath for buffers without stencil

--- radeon/radeon_surface.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index 80b1505..03b1c5d 100644 --- a/radeon/radeon_surface.c +++ b/radeon/radeon_surface.c @@ -911,7 +911,7 @@ static int eg_surface_best(struct radeo

[PATCH 1/2] radeon: simplify ZS buffer checking on r600

Setting those flags has no effect anywhere else. --- radeon/radeon_surface.c |9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index c80f7f4..5800c33 100644 --- a/radeon/radeon_surface.c +++ b/radeon/radeon_surface.c @@

[PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

If we don't need stencil, don't allocate it. If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth. --- radeon/radeon_surface.c | 19 +-- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index 5800

[PATCH] drm/radeon/kms: allow "invalid" DB formats as a means to disable DB

Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/evergreen_cs.c |6 -- drivers/gpu/drm/radeon/evergreend.h |2 ++ drivers/gpu/drm/radeon/r600_cs.c |6 -- drivers/gpu/drm/radeon/radeon_drv.c |3 ++- 4 files changed, 12 insertions(+), 5 deletions(-) diff --git

[PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

If we don't need stencil, don't allocate it. If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth. v2: actually do it correctly --- radeon/radeon_surface.c | 23 --- 1 file changed, 8 insertions(+), 15 deletions(-) diff --git a/radeon/radeon_surface.c b/

[PATCH 2/2] radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG

On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse wrote: > On Sun, Jul 29, 2012 at 1:04 PM, Marek Ol??k wrote: >> If we don't need stencil, don't allocate it. >> If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth. >> >> v2: actually do it correctly > > Big NAK > > We need to al

[PATCH] drm/radeon/kms: allow "invalid" DB formats as a means to disable DB

After some discussion in private, we've come to the conclusion that this is a very important fix. So if it's possible: Cc: stable at kernel.org Applicable to 3.5 stable kernel only. Marek On Sun, Jul 29, 2012 at 4:24 PM, Marek Ol??k wrote: > Signed-off-by: Marek Ol??k > --- > drivers/gpu/drm

[PATCH] drm/radeon/kms: allow "invalid" DB formats as a means to disable DB

Signed-off-by: Marek Ol??k Reviewed-by: Alex Deucher Reviewed-by: Michel D?nzer Cc: stable at vger.kernel.org [3.5] --- drivers/gpu/drm/radeon/evergreen_cs.c |6 -- drivers/gpu/drm/radeon/evergreend.h |2 ++ drivers/gpu/drm/radeon/r600_cs.c |6 -- drivers/gpu/drm/rade

[PATCH 1/2] drm/radeon: add some additional 6xx/7xx/EG register init

From: Alex Deucher - SMX_SAR_CTL0 needs to be programmed correctly to prevent problems with memory exports in certain cases. - VC_ENHANCE needs to be initialized on 6xx/7xx. Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/evergreen.c |3 +++ drivers/gp

[PATCH 2/2] drm/radeon: add support for STRMOUT_BASE_UPDATE on 7xx

From: Alex Deucher Required for streamout. Bump drm minor. Marek v2: fix pkt->count check Signed-off-by: Alex Deucher Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/r600_cs.c| 42 +++ drivers/gpu/drm/radeon/r600d.h |1 + drivers/gpu/drm/

[PATCH] drm/radeon/kms: set SX_MISC in the r6xx blit code

Mesa may set it to 1, causing all primitives to be killed. Signed-off-by: Marek Ol??k --- I hope it's right. drivers/gpu/drm/radeon/r600_blit_shaders.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_blit_shaders.c b/drivers/gpu/drm/radeo

[PATCH] r6xx: initialize SX_MISC

If Mesa set it to 1, the DDX would not render anything = the monitor would basically freeze. --- If it's right, please apply it to xf86-video-ati. I don't have commit access. src/r6xx_accel.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/r6xx_accel.c b/src/r6xx_acce

[PATCH] drm/radeon/kms: set SX_MISC in the r6xx blit code (v2)

Mesa may set it to 1, causing all primitives to be killed. v2: also update the r7xx code Signed-off-by: Marek Ol??k Cc: stable at kernel.org --- drivers/gpu/drm/radeon/r600_blit_shaders.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600

[PATCH] drm/radeon/kms: skip cb/db checking if SX_MISC is 1 on r600+

Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/evergreen_cs.c |8 drivers/gpu/drm/radeon/r600_cs.c |8 drivers/gpu/drm/radeon/reg_srcs/cayman|1 - drivers/gpu/drm/radeon/reg_srcs/evergreen |1 - drivers/gpu/drm/radeon/reg_srcs/r600 |

[PATCH 1/7] drm/radeon/kms: make some DRM errors more informative

Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/evergreen_cs.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c b/drivers/gpu/drm/radeon/evergreen_cs.c index 8bf576a..4674a68 100644 --- a/drivers/gpu/drm/radeon/evergreen_

[PATCH 3/7] drm/radeon/kms: optimize streamout checking for evergreen

Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/evergreen_cs.c | 37 ++-- 1 files changed, 21 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c b/drivers/gpu/drm/radeon/evergreen_cs.c index b39a089..0427b96 100644 --- a/drivers

[PATCH 2/7] drm/radeon/kms: compute GPU addresses correctly on evergreen

There are also two fixes: - In DRAW_INDEX_2, we read idx_value, but should have read idx+1. - When correcting SQ_VTX_CONSTANT_WORD1_0.SIZE, we should subtract the offset. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/evergreen_cs.c | 130 ++--- 1 files chan

[PATCH 4/7] drm/radeon/kms: skip db/cb/streamout checking when possible on evergreen

Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/evergreen_cs.c | 91 - 1 files changed, 66 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c b/drivers/gpu/drm/radeon/evergreen_cs.c index 0427b96..7327bc7 100644 --- a/driver

[PATCH 6/7] drm/radeon/kms: compute GPU addresses correctly on r600

Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/r600_cs.c | 89 +- 1 files changed, 68 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c index b3c40e0..d9ebec3 100644 --- a/drivers/gpu/drm/r

[PATCH 5/7] drm/radeon/kms: remove some unused variables in evergreen_cs_track

and document the other unused ones. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/evergreen_cs.c | 58 +++-- drivers/gpu/drm/radeon/reg_srcs/cayman| 12 ++ drivers/gpu/drm/radeon/reg_srcs/evergreen | 12 ++ 3 files changed, 30 insertions(+),

[PATCH 7/7] drm/radeon/kms: skip db/cb/streamout checking when possible on r600

Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/r600_cs.c | 270 +- 1 files changed, 150 insertions(+), 120 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c index d9ebec3..0ec3f20 100644 --- a/drivers/gpu/drm

[PATCH 0/2] libdrm_radeon support for Mullins

For the series: Reviewed-by: Marek Ol??k Marek On Thu, May 1, 2014 at 12:44 AM, Alex Deucher wrote: > This adds support for the new Mullins and Beema APUs. > > Samuel Li (2): > radeon: add Mullins chip family > radeon: add Mullins pci ids > > radeon/r600_pci_ids.h | 17 +

Re: [Radeon RV280] radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion »boi->space_accounted« failed, core dumped

Not in this case. You added a fail path to a function which isn't supposed to fail under these circumstances. No wonder Mesa couldn't cope with it. It really has nothing to do with your original issue. Marek On Fri, Aug 1, 2014 at 9:25 AM, Jochen Rollwagen wrote: > I've built the latest libdrm

Re: [Radeon RV280] radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion »boi->space_accounted« failed, core dumped

Does the attached libdrm patch fix the issue for you? Marek On Fri, Aug 1, 2014 at 1:16 PM, Marek Ol??k wrote: > Not in this case. You added a fail path to a function which isn't > supposed to fail under these circumstances. No wonder Mesa couldn't > cope with it. It really has nothing to do wit

[PATCH] radeon: allow write_reloc with unaccounted buffers to cope with Mesa R200 bug

From: Marek Ol??k --- I'm not really interested in studying the R200 driver to fix it. This has to suffice. radeon/radeon_cs_gem.c | 9 + 1 file changed, 9 insertions(+) diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c index b87c6b1..bcfa05b 100644 --- a/radeon/radeon_cs_g

[PATCH] radeon: allow write_reloc with unaccounted buffers to cope with Mesa R200 bug

Actually, please disregard this patch. I have found and fixed the real problem in mesa/r200. Marek On Mon, Aug 4, 2014 at 5:58 PM, Alex Deucher wrote: > On Fri, Aug 1, 2014 at 9:43 AM, Marek Ol??k wrote: >> From: Marek Ol??k >> >> --- >> >> I'm not really interested in studying the R200 driver

[PATCH] drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM

I'm afraid this won't always work and it can be a source of bugs. Userspace doesn't have to call GEM_WAIT_IDLE before a CPU access to a VRAM buffer. For example, consider a wait-idle request with a non-zero timeout, which is implemented as a loop which calls GEM_BUSY. Also, userspace can use fence

[PATCH] drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM

No, it doesn't. Marek On Tue, Aug 5, 2014 at 10:55 AM, Michel D?nzer wrote: > On 05.08.2014 07:01, Marek Ol??k wrote: >> I'm afraid this won't always work and it can be a source of bugs. >> >> Userspace doesn't have to call GEM_WAIT_IDLE before a CPU access to a >> VRAM buffer. For example, cons

[PATCH] drm/radeon: Always flush VM again on < CIK

So what's difference between WRITE_DATA with PFP vs ME? Would it also be preferable for DMA_DATA and COPY_DATA? Marek On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher wrote: > On Thu, Aug 7, 2014 at 3:46 AM, Michel D?nzer wrote: >> From: Michel D?nzer >> >> Not doing this causes piglit hangs[0] on

[PATCH] drm/radeon: signal all fences after lockup to avoid endless waiting in GEM_WAIT

This seems to be better. It can do about 3-5 resets correctly, then the GPU resuming fails: [ 246.882780] [drm:cik_resume] *ERROR* cik startup failed on resume and then the GPU is being reset again and again endlessly without success. The dmesg of the endless resets is attached. Marek On Sun,

[PATCH] drm/radeon: fix definition of WAIT_REG_MEM_OPERATION for CIK

From: Marek Ol??k Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/cikd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h index 203d2a0..cad6e8a 100644 --- a/drivers/gpu/drm/radeon/cikd.h +++ b/drivers/gpu/dr

[PATCH] drm/radeon: don't use PACKET2 on CIK

From: Marek Ol??k It is said to cause hangs. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/cik.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c index 2cd2ac0..44507a4 100644 --- a/drivers/gpu/drm/radeon/ci

[PATCH] radeon: sync with radeon_drm.h from kernel headers

From: Marek Ol??k Signed-off-by: Marek Ol??k --- I will make a new release and clean up Mesa definitions after this is committed. include/drm/radeon_drm.h | 31 --- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/include/drm/radeon_drm.h b/include/dr

[ANNOUNCE] libdrm 2.4.53

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Libdrm 2.4.53 has been released. Emil Velikov (1): freedreno: do not leak drmVersion Fran?ois Tigeot (1): Enable libkms by default on DragonFly Lucas Stach (1): modeprint: pretty print connector names Marek Ol??k (2): radeo

Radeon R700 multi-ring bug

Hi, If you submit a lot of graphics and DMA IBs interleaved, the graphics CS checker sometimes fails with this message: [ 3846.435661] Forbidden register 0x0014 in cs at 9 [ 3846.435664] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! This error is only used for type-0 packets, but we

Radeon R700 multi-ring bug

This test always reproduces the issue for me: piglit/bin/arb_vertex_buffer_object-vbo-subdata-many drawarrays -fbo -auto There are rejected IBs and it hangs sometimes. It started to fail with this commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=6d434252e239bc872549e59c64eb3d0e5dab0655

Radeon R700 multi-ring bug

Disabling DPM makes no difference. Marek On Sat, Apr 19, 2014 at 5:19 PM, Alex Deucher wrote: > On Sat, Apr 19, 2014 at 11:07 AM, Marek Ol??k wrote: >> This test always reproduces the issue for me: >> >> piglit/bin/arb_vertex_buffer_object-vbo-subdata-many drawarrays -fbo -auto >> >> There are

[PATCH v2] drm/radeon: evergreen/cayman indirect draw support

Reviewed-by: Marek Olšák Marek On Sat, Dec 13, 2014 at 3:32 AM, Glenn Kennard wrote: > Add the necessary set of commands to support OpenGL > indirect draw calls on evergreen/cayman devices that > do not have VM. > > Signed-off-by: Glenn Kennard > --- > Changes since patch V1: > * Removed mu

[PATCH] drm/radeon: fix VGT_GS_INSTANCE_CNT register

Hi Dave, You bumped the UMS driver version instead of the KMS one. Sorry for the late review, I actually noticed it when reading the code. Marek On Sat, Nov 30, 2013 at 12:07 PM, Dave Airlie wrote: > this register was incorrect for evergreen and cayman. > > Signed-off-by: Dave Airlie > --- >

[PATCH] drm/radeon: add a way to get and set initial buffer domains

From: Marek Ol??k When passing buffers between processes, the receiving process needs to know the original buffer domain, so that it doesn't accidentally move the buffer. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/radeon.h| 3 +++ drivers/gpu/drm/radeon/radeon_drv.c| 3

[PATCH] drm/radeon: fix display tiling setup on SI

Are you sure the index to si.tile_mode_array is correct? I wrote it for CI and I'm not sure if the index can be used for SI in this way too. Marek On Mon, Feb 17, 2014 at 8:21 PM, Alex Deucher wrote: > Apply the same logic as CI to SI for setting up the > display tiling parameters. The num bank

[PATCH 0/6] Radeon memory management improvements

This series improves performance for the cases when there is not enough VRAM for all buffers. First of all, I'd like to mention that if you set both VRAM and GTT domains for a buffer, you pretty much say you don't care where the buffer ends up. It usually makes the performance even worse. This

[PATCH 1/6] drm/radeon: add a way to get and set initial buffer domains

From: Marek Ol??k When passing buffers between processes, the receiving process needs to know the original buffer domain, so that it doesn't accidentally move the buffer. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/radeon.h| 3 +++ drivers/gpu/drm/radeon/radeon_drv.c| 3

[PATCH 4/6] drm/radeon: add buffers to the LRU list from smallest to largest

From: Marek Ol??k Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/radeon_cs.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index f28a8d8..d49a3f7 100644 --- a/drivers/gpu/drm/radeon/ra

[PATCH 3/6] drm/radeon: deduplicate code in radeon_gem_busy_ioctl

From: Marek Ol??k Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/radeon_gem.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index d7890f2..ccb7d0f 100644 --- a/drivers/gpu/drm/r

[PATCH 6/6] drm/radeon: limit how much memory TTM can move per IB according to VRAM usage

From: Marek Ol??k Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/radeon_cs.c | 2 +- drivers/gpu/drm/radeon/radeon_object.c | 87 +++--- drivers/gpu/drm/radeon/radeon_object.h | 3 +- 3 files changed, 84 insertions(+), 8 deletions(-) diff --git a/driver

[PATCH 5/6] drm/radeon: validate relocations in the order determined by userspace

From: Marek Ol??k Userspace should set the first 4 bits of drm_radeon_cs_reloc::flags to a number from 0 to 15. The higher the number, the higher the priority, which means a buffer with a higher number will be validated sooner. The old behavior is preserved: Buffers used for write are prioritize

[PATCH 2/6] drm/radeon: track memory statistics about VRAM and GTT usage and buffer moves

From: Marek Ol??k The statistics are: - VRAM usage in bytes - GTT usage in bytes - number of bytes moved by TTM The last one is actually a counter, so you need to sample it before and after command submission and take the difference. This is useful for finding performance bottlenecks. Userspace

[PATCH 0/6] Radeon memory management improvements

On Mon, Feb 24, 2014 at 5:40 PM, Christian K?nig wrote: > Am 24.02.2014 16:20, schrieb Marek Ol??k: >> 1) Add virtual memory support for VRAM. Our GPUs support virtual memory, >> which not only solves fragmentation issues, but it also allows each buffer >> to be partially in VRAM and partially in

[PATCH 0/6] Radeon memory management improvements

On Tue, Feb 25, 2014 at 11:11 AM, Christian K?nig wrote: > Am 24.02.2014 20:39, schrieb Marek Ol??k: > >> On Mon, Feb 24, 2014 at 5:40 PM, Christian K?nig >> wrote: >>> >>> Am 24.02.2014 16:20, schrieb Marek Ol??k: 1) Add virtual memory support for VRAM. Our GPUs support virtual memory,

[PATCH 1/6] drm/radeon: add a way to get and set initial buffer domains

From: Marek Ol??k When passing buffers between processes, the receiving process needs to know the original buffer domain, so that it doesn't accidentally move the buffer. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/radeon.h| 3 +++ drivers/gpu/drm/radeon/radeon_drv.c| 3

[PATCH 1/6] drm/radeon: add a way to get and set initial buffer domains

I'll send the other patches today. Marek On Wed, Feb 26, 2014 at 10:39 AM, Christian K?nig wrote: > Am 26.02.2014 01:44, schrieb Marek Ol??k: > >> From: Marek Ol??k >> >> When passing buffers between processes, the receiving process needs to >> know >> the original buffer domain, so that it doe

[PATCH 2/6] drm/radeon: track memory statistics about VRAM and GTT usage and buffer moves

On Mon, Feb 24, 2014 at 5:20 PM, Christian K?nig wrote: > Am 24.02.2014 16:20, schrieb Marek Ol??k: > >> From: Marek Ol??k >> >> The statistics are: >> - VRAM usage in bytes >> - GTT usage in bytes >> - number of bytes moved by TTM >> >> The last one is actually a counter, so you need to sample i

[PATCH 1/6] drm/radeon: add a way to get and set initial buffer domains

From: Marek Ol??k When passing buffers between processes, the receiving process needs to know the original buffer domain, so that it doesn't accidentally move the buffer. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/radeon.h| 3 +++ drivers/gpu/drm/radeon/radeon_drv.c| 3

[PATCH 6/6] drm/radeon: limit how much memory TTM can move per IB according to VRAM usage

From: Marek Ol??k Signed-off-by: Marek Ol??k Reviewed-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_cs.c | 2 +- drivers/gpu/drm/radeon/radeon_object.c | 87 +++--- drivers/gpu/drm/radeon/radeon_object.h | 3 +- 3 files changed, 84 insertions(+), 8 del

<    1   2   3   4   5   6   >