Is there a way not to use ninja with meson, because ninja redirects
all stderr output from gcc to stdout, which breaks many development
environments that expect errors in stderr?
I'm basically saying that if ninja can't keep gcc errors in stderr, I
wouldn't like any project that I might be involve
On Fri, Mar 17, 2017 at 12:11 AM, Dylan Baker wrote:
> Quoting Marek Olšák (2017-03-16 15:36:26)
>> Is there a way not to use ninja with meson, because ninja redirects
>> all stderr output from gcc to stdout, which breaks many development
>> environments that expect errors
On Fri, Mar 17, 2017 at 5:15 AM, Dylan Baker wrote:
> Quoting Marek Olšák (2017-03-16 18:53:59)
>> On Fri, Mar 17, 2017 at 12:11 AM, Dylan Baker wrote:
>> > Quoting Marek Olšák (2017-03-16 15:36:26)
>> >> Is there a way not to use ninja with meson, because ninja red
On Wed, Mar 22, 2017 at 6:26 PM, Jose Fonseca wrote:
> On 16/03/17 22:36, Marek Olšák wrote:
>>
>> Is there a way not to use ninja with meson, because ninja redirects
>> all stderr output from gcc to stdout, which breaks many development
>> environments that expect
amdgpu/drm: add AMDGPU_HW_IP_VCN_DEC
amdgpu/drm: add AMDGPU_HW_IP_VCN_ENC
Marek Olšák (1):
Bump version to 2.4.81
Nicolai Hähnle (3):
amdgpu: add the interface of waiting multiple fences
amdgpu: add a test for amdgpu_cs_wait_fences
amdgpu: add missing extern &qu
Reviewed-by: Marek Olšák
Marek
On Mon, Sep 5, 2016 at 2:46 PM, Jussi Kukkonen
wrote:
> Add --with-cunit to make it easier to do reproducible builds. Default
> is still to probe cunit and build opportunistically.
>
> Signed-off-by: Jussi Kukkonen
> ---
> configure.ac | 14 --
>
On Thu, Oct 20, 2016 at 8:31 AM, Daniel Vetter wrote:
> On Wed, Oct 19, 2016 at 6:46 PM, Marek Olšák wrote:
We've had per buffer metadata in Radeon since KMS, which I believe first
appeared in 2009. It's 4 bytes large and is used to communicate tiling
flags between Mesa, DDX, and
On Wed, Jan 4, 2017 at 12:43 AM, James Jones wrote:
> On 01/03/2017 03:38 PM, Marek Olšák wrote:
>>
>> On Thu, Oct 20, 2016 at 8:31 AM, Daniel Vetter wrote:
>>>
>>> On Wed, Oct 19, 2016 at 6:46 PM, Marek Olšák wrote:
>>
>> We've had per buffer metadata in Radeon since KMS, which I be
Thanks for all the feedback. Things are much clearer now.
Yeah, we can use the BO modifiers for simple 2D images / planes if
that's the general direction. I think we can even stuff the
compression data buffer offset into those 64 bits, considering it's
not very large (e.g. below 4GB and low bits a
Hi,
The following branches add SI support to the amdgpu side of our
graphics driver stack.
git://people.freedesktop.org/~mareko/mesa amdgpu-si
git://people.freedesktop.org/~mareko/libdrm amdgpu-si
git://people.freedesktop.org/~mareko/xf86-video-amdgpu amdgpu-si
Thanks to Ronie Salgado for start
From: Marek Olšák
---
radeon/radeon_surface.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 5ec9745..1424660 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -957,8 +957,10 @@ static int eg
From: Marek Olšák
It warns for all "{}" initializers. Well, I want us to use {}.
---
configure.ac | 3 ++-
intel/intel_decode.c | 2 --
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index c8c4ace..057a846 100644
--- a/configure.ac
+++ b/conf
Hi,
These are libdrm_amdgpu patches harvested from an internal branch.
The first patch is a revert I had to make to fix the build. Yeah,
sequence_mutex should be renamed to a more appropriate name. That can be done
as a follow-up.
One notable change is the addition of DRM_IOCTL_AMDGPU_WAIT_FEN
From: Marek Olšák
This reverts commit f6f25d67a9c0d26be9b8021a45f2acf3a4042ade.
Required by the new semaphore patches.
---
amdgpu/amdgpu_cs.c | 10 ++
amdgpu/amdgpu_internal.h | 3 +++
2 files changed, 13 insertions(+)
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index
From: Junwei Zhang
Signed-off-by: Junwei Zhang
Reviewed-by: Christian König
Reviewed-by: Jammy Zhou
---
amdgpu/amdgpu.h | 22 +++
amdgpu/amdgpu_cs.c | 71
include/drm/amdgpu_drm.h | 27 ++
3 files cha
From: Michel Dänzer
CC amdgpu_bo.lo
../../amdgpu/amdgpu_bo.c: In function 'amdgpu_create_bo_from_user_mem':
../../amdgpu/amdgpu_bo.c:539:12: warning: assignment makes integer from pointer
without a cast [-Wint-conversion]
args.addr = cpu;
^
Reviewed-by: Jammy Zhou
---
a
From: "monk.liu"
we don't support non-page-aligned cpu pointer anymore
Signed-off-by: monk.liu
Reviewed-by: Christian König
---
amdgpu/amdgpu_bo.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 1a5a401..61db58c 10
From: Chunming Zhou
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
amdgpu/amdgpu_bo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 2ae1c18..d30fd1e 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@
From: Chunming Zhou
the semaphore is a binary semaphore. the work flow is:
1. create sem
2. signal sem
3. wait sem, reset sem after signalled
4. destroy sem.
Signed-off-by: Chunming Zhou
Reviewed-by: Jammy Zhou
Reviewed-by: Christian König
---
amdgpu/amdgpu.h | 65
From: Chunming Zhou
Signed-off-by: Chunming Zhou
Reviewed-by: Jammy Zhou
Reviewed-by: Christian König
---
tests/amdgpu/basic_tests.c | 133 +
1 file changed, 133 insertions(+)
diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
in
From: "monk.liu"
Signed-off-by: monk.liu
---
amdgpu/amdgpu.h| 3 ++-
amdgpu/amdgpu_cs.c | 12 +---
include/drm/amdgpu_drm.h | 3 ++-
tests/amdgpu/basic_tests.c | 2 +-
4 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgp
From: Junwei Zhang
Signed-off-by: Junwei Zhang
Reviewed-by: Michel Dänzer
Reviewed-by: David Zhou
Reviewed-by: Christian König
---
amdgpu/amdgpu_cs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 5c7a3a3..82fa805 10064
From: Junwei Zhang
Signed-off-by: Junwei Zhang
Reviewed-by: Jammy Zhou
---
tests/amdgpu/basic_tests.c | 100 +
1 file changed, 100 insertions(+)
diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index e489e6e..a666d32 100644
--- a
On Wed, Jan 13, 2016 at 11:43 AM, Christian König
wrote:
> Am 12.01.2016 um 22:30 schrieb Alex Deucher:
>>
>> On Tue, Jan 12, 2016 at 4:23 PM, Marek Olšák wrote:
>>>
>>> Hi,
>>>
>>> These are libdrm_amdgpu patches harvested from an internal branch.
>>>
>>> The first patch is a revert I had to
On Fri, Jan 15, 2016 at 12:12 PM, Emil Velikov
wrote:
> On 12 January 2016 at 23:14, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> It warns for all "{}" initializers. Well, I want us to use {}.
>> ---
>> configure.ac | 3 ++-
>> intel/intel_decode.c | 2 --
> The whole of libdrm, mi
OK. Reviewed-by: Marek Olšák
Marek
On Wed, Sep 2, 2020 at 6:31 AM Bas Nieuwenhuizen
wrote:
> On Fri, Aug 7, 2020 at 9:43 PM Marek Olšák wrote:
> >
> > On Tue, Aug 4, 2020 at 5:32 PM Bas Nieuwenhuizen <
> b...@basnieuwenhuizen.nl> wrote:
> >>
> >
On Tue, Aug 4, 2020 at 5:32 PM Bas Nieuwenhuizen
wrote:
> This expose modifier support on GFX9+.
>
> Only modifiers that can be rendered on the current GPU are
> added. This is to reduce the number of modifiers exposed.
>
> The HW could expose more, but the best mechanism to decide
> what to expo
There are a few cases when the flags can change, for example DCC can be
disabled due to a hw limitation in the 3d engine. Modifiers give the
misleading impression that they help with that, but they don't. They don't
really help with anything.
Marek
On Mon., Aug. 10, 2020, 08:30 Christian König, <
On Wed, Aug 12, 2020 at 9:54 AM Daniel Vetter wrote:
> On Tue, Aug 11, 2020 at 09:42:11AM -0400, Marek Olšák wrote:
> > There are a few cases when the flags can change, for example DCC can be
> > disabled due to a hw limitation in the 3d engine. Modifiers give the
> > misle
Hi Sasha,
I disagree with this. Bumping the driver version will have implications on
other new features, because it's like an ABI barrier exposing new
functionality.
Marek
On Thu, May 7, 2020 at 10:28 AM Sasha Levin wrote:
> From: Marek Olšák
>
> [ U
: fix unrelated changes sent with the patch
>
> Signed-off-by: Simon Ser
> Reviewed-by: Daniel Vetter
> Cc: Daniel Stone
> Cc: Bas Nieuwenhuizen
> Cc: Dave Airlie
> Cc: Marek Olšák
> ---
> include/uapi/drm/drm_fourcc.h | 15 +++
> 1 file changed, 15 in
TMZ is more complicated. If there is a TMZ buffer used by a command buffer,
then all other used buffers must also be TMZ or read only. If no TMZ
buffers are used by a command buffer, then TMZ is disabled. If a context is
not secure, TMZ is also disabled. A context can switch between secure and
non-
[+ dri-devel]
On Mon, Jun 6, 2016 at 8:42 AM, Mathieu Malaterre wrote:
> Hi,
>
> Before reporting a possible invalid bug report. Does anyone knows why
> radeaonfb is not configured the same way radeon is ? For instance on a
> PowerPC machine, when Open Firmware Frame Buffer is used (OFfb), I
> ca
On Mon, Jan 18, 2016 at 3:45 PM, Emil Velikov
wrote:
> On 15 January 2016 at 17:24, Marek Olšák wrote:
>> On Fri, Jan 15, 2016 at 12:12 PM, Emil Velikov
>> wrote:
>>> On 12 January 2016 at 23:14, Marek Olšák wrote:
From: Marek Olšák
It warns for all "{}" initializers. We
On Mon, Jan 18, 2016 at 5:05 PM, Emil Velikov
wrote:
> On 18 January 2016 at 17:43, Marek Olšák wrote:
>> On Mon, Jan 18, 2016 at 3:45 PM, Emil Velikov
>> wrote:
>>> On 15 January 2016 at 17:24, Marek Olšák wrote:
On Fri, Jan 15, 2016 at 12:12 PM, Emil Velikov >>> gmail.com> wrote:
>
On Thu, Jan 21, 2016 at 11:51 AM, Emil Velikov
wrote:
> On 18 January 2016 at 22:53, Marek Olšák wrote:
>> Try explaining that to people who have a compulsion to fix them or
>> argue about them. :) Ignore? REALLY? IGNORE???
>>
> Now that we have a few people off your back can you please point
On Thu, Jan 21, 2016 at 2:09 PM, Emil Velikov
wrote:
> On 21 January 2016 at 12:08, Marek Olšák wrote:
>> On Thu, Jan 21, 2016 at 11:51 AM, Emil Velikov
>> wrote:
>>> On 18 January 2016 at 22:53, Marek Olšák wrote:
Try explaining that to people who have a compulsion to fix them or
>>
On Fri, Jan 22, 2016 at 6:13 PM, Emil Velikov
wrote:
> On 21 January 2016 at 16:58, Marek Olšák wrote:
>> On Thu, Jan 21, 2016 at 2:09 PM, Emil Velikov
>> wrote:
>>> On 21 January 2016 at 12:08, Marek Olšák wrote:
On Thu, Jan 21, 2016 at 11:51 AM, Emil Velikov >>> gmail.com> wrote:
>
The resource flags actually tell you what you can do. If the COHERENT
flag is set, the mapping must be cached. If it's unset, it's up to
you.
If write-combining is faster for vertex uploads, then Glamor shouldn't
set the coherent flag.
Marek
On Thu, Jul 17, 2014 at 12:01 PM, Michel D?nzer wrote
Like I said at patch 4, this would be okay if the COHERENT flag wasn't set.
If you removed the PERSISTENT flag from the conditional, the placement
of persistent non-coherent buffers would be driven by the "usage",
meaning that you would be able to get any kind of placement you want.
Marek
On Thu
On Thu, Jul 17, 2014 at 12:01 PM, Michel D?nzer wrote:
> Mesa patches:
>
> [PATCH 1/5] winsys/radeon: Use separate caching buffer managers for
> [PATCH 2/5] r600g/radeonsi: Use write-combined CPU mappings of some
> [PATCH 3/5] r600g/radeonsi: Prefer VRAM for CPU -> GPU streaming
For these 3 patch
If the requirements of GL_MAP_COHERENT_BIT are satisfied, then the
patch is okay.
Marek
On Fri, Jul 18, 2014 at 5:19 AM, Michel D?nzer wrote:
> On 17.07.2014 21:00, Marek Ol??k wrote:
>> On Thu, Jul 17, 2014 at 12:01 PM, Michel D?nzer
>> wrote:
>>> From: Michel D?nzer
>>>
>>> This is hopeful
On Fri, Jul 18, 2014 at 5:47 PM, Christian K?nig
wrote:
> Am 18.07.2014 05:07, schrieb Michel D?nzer:
[PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on >= SI
>>>
>>> I'm still not very keen with this change since I still don't understand
>>> the reason why it's faster than with GT
GL_MAP_READ_BIT is always unconditionally set for glBufferData, which
is the most-used function. However, st/mesa can look at the
immutability flag to distinguish between BufferData and BufferStorage
before pipe_buffer_create is called, and set the read flag if the
caller is BufferStorage and GL_MA
On Fri, Jul 18, 2014 at 5:19 AM, Michel D?nzer wrote:
> On 17.07.2014 21:00, Marek Ol??k wrote:
>> On Thu, Jul 17, 2014 at 12:01 PM, Michel D?nzer
>> wrote:
>>> From: Michel D?nzer
>>>
>>> This is hopefully safe: The kernel makes sure writes to these mappings
>>> finish before the GPU might sta
On Fri, Jul 18, 2014 at 7:47 PM, Marek Ol??k wrote:
> On Fri, Jul 18, 2014 at 5:47 PM, Christian K?nig
> wrote:
>> Am 18.07.2014 05:07, schrieb Michel D?nzer:
>
> [PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on >= SI
I'm still not very keen with this change since I stil
This sounds good to me.
Marek
On Wed, Jul 23, 2014 at 8:32 AM, Michel D?nzer wrote:
> On 18.07.2014 20:45, Marek Ol??k wrote:
>> If the requirements of GL_MAP_COHERENT_BIT are satisfied, then the
>> patch is okay.
>
> AFAICT GL_MAP_COHERENT_BIT simply means the app doesn't need to call
> glMemor
On Wed, Jul 23, 2014 at 9:21 AM, Michel D?nzer wrote:
> On 23.07.2014 15:42, Christian K?nig wrote:
>> Am 23.07.2014 05:54, schrieb Michel D?nzer:
>>> On 21.07.2014 17:07, Christian K?nig wrote:
Am 19.07.2014 03:15, schrieb Michel D?nzer:
> On 19.07.2014 00:47, Christian K?nig wrote:
From: Marek Ol??k
---
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 9c3a192..8a1fe7d 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -1914,7 +1914,7 @@ static void cik_get_
I think the problem is the driver hasn't called
radeon_cs_space_add_persistent_bo.
Marek
On Fri, Jul 25, 2014 at 6:32 PM, Jochen Rollwagen
wrote:
> I've recently ported the peopsxgl OpenGL-GPU-Plugin for the pcsx
> Playstation1 Emulator to the Powerpc-architecture. When running certain
> games
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Libdrm 2.4.56 has been released. It fixes MSAA for the Radeon Hawaii GPU.
Andreas Boll (1):
libdrm: Fix drm.h include in qxl drm header file
Marek Ol??k (2):
radeon: fix typo in sample split / fixes MSAA on Hawaii
configure.ac: bum
Reviewed-by: Marek Ol??k
Marek
On Thu, Jul 31, 2014 at 11:43 AM, Michel D?nzer wrote:
> From: Michel D?nzer
>
> Signed-off-by: Michel D?nzer
> ---
> src/gallium/drivers/radeon/r600_buffer_common.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/src/galli
Reviewed-by: Marek Ol??k
Marek
On Thu, Jul 31, 2014 at 11:43 AM, Michel D?nzer wrote:
> From: Michel D?nzer
>
> Signed-off-by: Michel D?nzer
> ---
> src/gallium/drivers/radeon/r600_buffer_common.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/src/g
Thanks. This patch is:
Reviewed-by: Marek Ol??k
Marek
On Mon, Jun 2, 2014 at 5:33 PM, Christian K?nig
wrote:
> From: Christian K?nig
>
> And also domain to prefered_domains. That matches better
> what those values represent.
>
> Signed-off-by: Christian K?nig
> Cc: Marek Ol??k
> ---
> dri
Sorry to tell you the bad news. This patch doesn't fix the hangs on my machine.
I tested drm-next-3.16 from Alex's tree. I also switched copying from
SDMA to CP DMA, which hung too.
I also tried this:
git checkout (the problematic commit):
6d2f294 - drm/radeon: use normal BOs for the page tables
I only tested Bonaire. I can test Cape Verde if needed.
Marek
On Wed, Jun 11, 2014 at 11:29 AM, Christian K?nig
wrote:
> Crap, I already wanted to check back with you if that really fixes your
> problems.
>
> Thanks for the info, this crash also only happens on CIK doesn't it?
>
> Christian.
>
>
Hi,
With my "force_gtt" patch, Cape Verde is unstable too, so all GCN
chips are affected.
I recommend applying that patch, because it will reproduce the problem
faster. Without it, the hangs are very rare and it may take a while
before they occur.
Marek
On Thu, Jun 12, 2014 at 1:23 PM, Christia
Hi Michel,
3.15 doesn't contain Christian's fix yet, so it should be always
broken for everybody. The fix is currently only in 3.16.
Alternatively, you can cherry-pick the fix to 3.15, but it doesn't
apply cleanly.
There is a workaround in 3.15 which disables sDMA and uses CP DMA for
copying buf
Signed-off-by: Marek Olšák
---
include/uapi/drm/radeon_drm.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 321d4ac..0b6740a 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm
---
src/gallium/drivers/r300/r300_state.c | 2 +-
src/gallium/drivers/r300/r300_texture.c | 4 ++--
src/gallium/drivers/r600/r600_texture.c | 13 -
src/gallium/drivers/radeonsi/r600_texture.c | 13 -
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 12
Basically just pass RADEON_TILING_R600_SCANOUT everywhere.
Hopefully I didn't miss anything. This is only compile-tested.
Signed-off-by: Marek Olšák
---
src/drmmode_display.c | 44 +---
src/radeon_bo_helper.c | 11 +--
src/radeon_drm.h
---
include/drm/radeon_drm.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 86cef15..1e8713c 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -806,8 +806,9 @@ struct drm_radeon_gem_create {
Please disregard this patch and the related patches. It causes a
regression which I haven't been able to fix yet.
Marek
On Mon, Aug 12, 2013 at 8:19 PM, Marek Olšák wrote:
> Basically just pass RADEON_TILING_R600_SCANOUT everywhere.
> Hopefully I didn't miss anything. This
This fixes VM protection faults.
I have a new piglit test which can iterate over all possible widths, heights,
and depths (including NPOT) and tests mipmapping with various texture targets.
After this is committed, I'll make a new release of libdrm and bump
the libdrm version requirement in Mesa.
On Thu, Sep 19, 2013 at 4:41 PM, Michel Dänzer wrote:
> On Don, 2013-09-19 at 14:33 +0200, Marek Olšák wrote:
>> This fixes VM protection faults.
>>
>> I have a new piglit test which can iterate over all possible widths, heights,
>> and depths (including NPOT) and te
BTW, the intuitive explanation of the fix is that we have to minify
the pitch (or POT width) instead of the NPOT width.
Marek
On Thu, Sep 19, 2013 at 6:37 PM, Marek Olšák wrote:
> On Thu, Sep 19, 2013 at 4:41 PM, Michel Dänzer wrote:
>> On Don, 2013-09-19 at 14:33 +0200, Marek Ol
n particular, I think changing the values of npix_x/y/z would break
resource_copy_region for NPOT compressed textures in radeonsi, which
is kind of a mess at the moment.
Marek
On Fri, Sep 20, 2013 at 4:14 PM, Michel Dänzer wrote:
> On Don, 2013-09-19 at 18:37 +0200, Marek Olšák wrote:
>>
From: Marek Olšák
After a lockup, fences are not signalled sometimes, causing
the GEM_WAIT_IDLE ioctl to never return, which sometimes results
in an X server freeze.
This fixes only one of many deadlocks which can occur during a lockup.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/radeon
deed signal all fences manually.
>
> Signalling all fences regardless of the outcome of the reset creates problems
> with both types of partial resets.
>
> Christian.
>
> Marek Olšák schrieb:
>
>>From: Marek Olšák
>>
>>After a lockup, fences are not signal
I think the function should stay in the header file. It's used in
performance-critical code, so we want it to be inlined.
Marek
On Fri, May 16, 2014 at 11:43 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> Saves about 5k of text
>
>textdata bss dec hex filename
> 14080360
From: Marek Ol??k
It hangs the hardware.
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/radeon_cs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 2b6e0eb..2b78191 100644
--- a/drivers/gpu/drm/rade
Yeah, feel free to add the Cc: stable tag.
Marek
On Tue, May 27, 2014 at 11:08 AM, Christian K?nig
wrote:
> Am 27.05.2014 02:56, schrieb Marek Ol??k:
>
>> From: Marek Ol??k
>>
>> It hangs the hardware.
>>
>> Signed-off-by: Marek Ol??k
>
>
> Reviewed-by: Christian K?nig
>
> Maybe CC stable as
Hi Christian,
I test on Bonaire (ChipID = 0x665c). Unfortunately, the hangs are not
fixed yet. They are very rare and very random. Therefore, I have come
up with a patch which evicts page tables between IBs. See the
attachment. With that patch applied, the system starts fine, compiz
and glxgears w
Can disable evictions for page tables, e.g. by removing them from the LRU list?
Marek
On Thu, May 29, 2014 at 6:30 PM, Christian K?nig
wrote:
> Hi Marek & Alex,
>
> I've found the issue why forcefully evicting page tables sometimes crashes
> the box.
>
> Well this is a typical hexdump page table
Grigori,
you can git-checkout the commit before and after the memory management
changes, compile both and test them.
Marek
On Fri, May 30, 2014 at 2:30 AM, Grigori Goronzy wrote:
> On 13.05.2014 22:27, Marek Ol??k wrote:
>>
>> I applied these two patches Christian sent to dri-devel:
>>
>> drm/r
That's right.
Also, you probably want to enable automatic addition of the git-sha1
to the kernel version in menuconfig, there is an option for it, so
that you can have several kernels with the same version but different
sha1 installed.
Marek
On Fri, May 30, 2014 at 1:46 PM, Grigori Goronzy wrot
Hi Glenn,
First of all, evergreen_cs_track_check only has to be called for the
packets that execute a draw call. It's useless to call it for
INDEX_BASE, INDEX_BUFFER_SIZE, and SET_BASE.
There has never been index buffer bounds checking in the CS checker
and this patch doesn't change that, so no a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Libdrm 2.4.63 has been released. It contains the new libdrm_amdgpu library.
Alan Coopersmith (1):
include & directly for major() and minor()
Alex Deucher (10):
drm: consolidate common list implementations (v2)
drm: add util_math
[- xorg-announce]
Hi Jammy,
You can push it whenever you like. I can also make a new libdrm
release whenever I like. There is no strict schedule for libdrm. If
you want another release (e.g. Catalyst needs it, etc.), just let me
know.
Libdrm releases are mostly driven by needs of other projects
From: Marek Olšák
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index e6fa278..0fcc0bd 100644
--- a/drivers/gpu/d
FYI, this is for drm-next-4.3.
Marek
On Tue, Aug 18, 2015 at 11:58 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Signed-off-by: Marek Olšák
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amd
Reviewed-by: Marek Ol??k
Marek
On Thu, Aug 28, 2014 at 8:56 AM, Michel D?nzer wrote:
> From: Michel D?nzer
>
> This allows the kernel to prevent such BOs from ever being stored in the
> CPU inaccessible part of VRAM.
>
> Signed-off-by: Michel D?nzer
> ---
> src/gallium/drivers/radeon/r600_bu
BTW, we can recycle fences in userspace just like we recycle buffers.
That should make the create/close overhead non-existent.
Marek
On Sat, Sep 13, 2014 at 2:25 PM, Christian K?nig
wrote:
>> Doing such combining and cleaning up fds as soon as they have been passed
>> on should keep each applica
For the series:
Reviewed-by: Marek Olšák
Marek
On Fri, Sep 28, 2018 at 10:46 AM Andrey Grodzovsky
wrote:
>
> Seems like AI and RV requires uncashed memory mapping to be able
> to pickup value written to memory by CPU after the WAIT_REG_MEM
> command was already launched.
> .
&g
Yes, Andrey has commit rights.
Marek
On Wed, Oct 3, 2018 at 10:34 AM Christian König
wrote:
>
> Thanks for keeping working on this.
>
> Series is Reviewed-by: Christian König as well.
>
> Do you now have commit rights?
>
> Christian.
>
> Am 02.10.2018 um 22:47 sc
Hopefully this answers some questions.
Other parameters that affect tiling layouts are GB_ADDR_CONFIG (all
chips) and MC_ARB_RAMCFG (GFX6-8 only), and those vary with each chip.
Some 32bpp 1D tiling layouts are compatible across all chips (1D
display tiling is the same as SW_256B_D if Bpp == 4).
On Fri, Sep 7, 2018 at 5:55 AM, Bas Nieuwenhuizen
wrote:
> On Fri, Sep 7, 2018 at 6:51 AM Marek Olšák wrote:
>>
>> Hopefully this answers some questions.
>>
>> Other parameters that affect tiling layouts are GB_ADDR_CONFIG (all
>> chips) and MC_ARB_RAMCFG (GFX6-
This will break old UMDs that didn't set the flags correctly. Instead,
UMDs should stop using amdgpu_bo_va_op if they want to set the flags.
Marek
On Thu, Sep 27, 2018 at 3:05 PM Andrey Grodzovsky
wrote:
>
> Signed-off-by: Andrey Grodzovsky
> ---
> amdgpu/amdgpu_bo.c | 5 +++--
> 1 file changed
hash table
amdgpu: Destroy fd_hash table when the last device is removed.
José Roberto de Souza (2):
intel: Introducing Whiskey Lake platform
intel: Introducing Amber Lake platform
Kevin Strasser (1):
xf86drm: Be sure to closedir before return
Marek Olšák (3):
a
Signed-off-by: Marek Ol??k
---
include/uapi/drm/radeon_drm.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 321d4ac..0b6740a 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
---
include/drm/radeon_drm.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 86cef15..1e8713c 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -806,8 +806,9 @@ struct drm_radeon_gem_create {
---
src/gallium/drivers/r300/r300_state.c | 2 +-
src/gallium/drivers/r300/r300_texture.c | 4 ++--
src/gallium/drivers/r600/r600_texture.c | 13 -
src/gallium/drivers/radeonsi/r600_texture.c | 13 -
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 12
Basically just pass RADEON_TILING_R600_SCANOUT everywhere.
Hopefully I didn't miss anything. This is only compile-tested.
Signed-off-by: Marek Ol??k
---
src/drmmode_display.c | 44 +---
src/radeon_bo_helper.c | 11 +--
src/radeon_drm.h | 5
Please disregard this patch and the related patches. It causes a
regression which I haven't been able to fix yet.
Marek
On Mon, Aug 12, 2013 at 8:19 PM, Marek Ol??k wrote:
> Basically just pass RADEON_TILING_R600_SCANOUT everywhere.
> Hopefully I didn't miss anything. This is only compile-tested
The registers aren't listed because they are not safe and they need to
be checked by the CS checker.
NAK.
Marek
On Mon, Dec 2, 2013 at 8:34 AM, Alexandre Demers
wrote:
> Added some missing registers listed in documentation.
>
> Signed-off-by: Alexandre Demers
> ---
> drivers/gpu/drm/radeon/re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
libdrm 2.4.50 has been released. It fixes a critical bug for Radeon Southern
Islands GPUs.
Keith Packard (1):
intel: Track known prime buffers for re-use
Marek Ol??k (1):
Bump the version to 2.4.50
Michel D?nzer (1):
radeon: Updat
Hi Lauri,
FYI, since the userspace driver sends end-of-frame markers to the
kernel, the radeon kernel driver knows the current frame number and it
can also save the frame number of the last use of each buffer. We
should definitely use that to measure the buffer hotness, or just
prevent eviction if
On Mon, Dec 9, 2013 at 9:30 PM, Lauri Kasanen wrote:
> On Mon, 9 Dec 2013 20:28:21 +0100
> Marek Ol??k wrote:
>
> Hi,
>
>> FYI, since the userspace driver sends end-of-frame markers to the
>> kernel, the radeon kernel driver knows the current frame number and it
>> can also save the frame number
On Tue, Dec 10, 2013 at 1:49 AM, Michel D?nzer wrote:
> On Mon, 2013-12-09 at 23:45 +0100, Marek Ol??k wrote:
>> On Mon, Dec 9, 2013 at 9:30 PM, Lauri Kasanen wrote:
>> >
>> > Note that the hotness calculation will be in userspace, as only there
>> > are the necessary counters available. So the f
On Tue, Dec 10, 2013 at 12:59 PM, Lauri Kasanen wrote:
> On Mon, 9 Dec 2013 23:45:12 +0100
> Marek Ol??k wrote:
>
>> > Note that the hotness calculation will be in userspace, as only there
>> > are the necessary counters available. So the finished hotness score
>> > will be passed to the kernel,
101 - 200 of 554 matches
Mail list logo
