Reviewed-by: Marek Ol??k
Marek
On Tue, Dec 10, 2013 at 6:42 PM, Alex Deucher wrote:
> Some users report hitting a divide by 0 with the tile split in
> certain apps. Tile_split shouldn't ever be 0 unless the surface
> structure was not properly initialized. I think there may be some
> cases wh
Some of the code seems to be copy-pasted from
dri2_drawable_process_buffers. The MSAA color and depth-stencil
texture allocation could be moved to a common function.
Marek
On Sat, Dec 14, 2013 at 2:25 AM, Keith Packard wrote:
> Provide the hook to pull textures out of __DRIimage structures and u
AMDGPU_GEM_CREATE_GFX12_DCC is set on 90% of all memory allocations, and
almost all of them are not displayable. Shouldn't we use a different way to
indicate that we need a non-power-of-two alignment, such as looking at the
alignment field directly?
Marek
On Tue, Jul 16, 2024, 11:45 Arunpravin Pa
The reason is that our DCC requires 768K alignment in some cases. I haven't
read this patch series, but one way to do that is to align to 256K,
overallocate by 512K, and then not use either 0, 256K, or 512K at the
beginning to get to 768K alignment.
Marek
On Tue, Jul 23, 2024, 11:04 Matthew Auld
Attached is the revert commit that works for me. Tested with Radeon
6800 and Radeon 7900XTX.
Marek
Marek
On Wed, Jun 19, 2024 at 9:50 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 13.06.24 um 07:59 schrieb Marek Olšák:
> > Hi Thomas,
> >
> > Commit 9eac534db0013aff9
Hi Thomas,
FYI, this doesn't fix the issue of lightdm not being able to start for me.
Marek
Marek
On Tue, Jun 25, 2024 at 4:18 AM Thomas Zimmermann wrote:
>
> Retrieving the system framebuffer's parent device in sysfb_init()
> increments the parent device's reference count. Hence release the
The most extreme ping-ponging is mitigated by throttling buffer moves
in the kernel, but it only works without VM_ALWAYS_VALID and you can
set BO priorities in the BO list. A better approach that works with
VM_ALWAYS_VALID would be nice.
Marek
On Wed, Apr 24, 2024 at 1:12 PM Friedrich Vock wrote
The idea sounds good.
Marek
On Sat, Sep 30, 2017 at 3:55 AM, Chunming Zhou wrote:
> My mean is like the attached, I revert part of yours.
>
> Regards,
>
> David zhou
>
>
>
> On 2017年09月29日 22:15, Marek Olšák wrote:
>>
>> On Fri, Sep 29, 2017 at 4:13 PM,
data corruption issue
Jan Vesely (1):
amdgpu: Do not write beyond allocated memory when parsing ids
Marek Olšák (7):
amdgpu: print error messages when amdgpu_device_initialize is failing
include: sync drm.h and amdgpu_drm.h with airlied/drm-next
amdgpu: add sync_file import
sounds good.
>
> Marek
>
> On Sat, Sep 30, 2017 at 3:55 AM, Chunming Zhou wrote:
>> My mean is like the attached, I revert part of yours.
>>
>> Regards,
>>
>> David zhou
>>
>>
>>
>> On 2017年09月29日 22:15, Marek Olšák wrote:
>&g
whitespace issues
Marek Olšák (1):
configure.ac: bump version for release
git tag: libdrm-2.4.86
https://dri.freedesktop.org/libdrm/libdrm-2.4.86.tar.bz2
MD5: 8dabf172c9695c24d000cbddfa849a82 libdrm-2.4.86.tar.bz2
SHA1: b2c428326843dfaa5fb88899b8dfaa43b792dc70 libdrm-2.4.86.tar.bz2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
libdrm 2.4.87 has been released.
Marek Olšák (2):
amdgpu: fix 32-bit build
configure.ac: bump version for release
git tag: libdrm-2.4.87
https://dri.freedesktop.org/libdrm/libdrm-2.4.87.tar.bz2
MD5: b4f9063838559d08649d45fec2d1184a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
libdrm 2.4.88 has been released.
Andrey Grodzovsky (1):
amdgpu: Fix wrappers for AMDGPU_VM IOCTL.
Marek Olšák (1):
configure.ac: bump version for release
git tag: libdrm-2.4.88
https://dri.freedesktop.org/libdrm/libdrm-2.4.88
On Thu, Jul 6, 2017 at 3:17 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This adds kernel semaphore support to the command submission
> interface in what should be a backwards compatible manner,
> it adds a new command submission API.
>
> Signed-off-by: Dave Airlie
> ---
> amdgpu/amdgpu.h
On Fri, Sep 1, 2017 at 5:36 PM, Marek Olšák wrote:
> On Thu, Jul 6, 2017 at 3:17 AM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This adds kernel semaphore support to the command submission
>> interface in what should be a backwards compatible manner,
>> it
What's the difference between HandleToFD and ExportSyncFile?
Thanks,
Marek
On Sat, Jun 17, 2017 at 3:06 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> These ioctls are now in drm next so add the first set of libdrm APIs.
>
> Signed-off-by: Dave Airlie
> ---
> include/drm/drm.h | 26 ++
On Fri, Sep 8, 2017 at 10:08 PM, Dave Airlie wrote:
>
>
> On 9 Sep. 2017 2:30 am, "Marek Olšák" wrote:
>
> What's the difference between HandleToFD and ExportSyncFile?
>
>
> One just gives you an FD for sharing the syncobj itself, the other exports
>
From: Marek Olšák
for being able to convert an amdgpu fence into one of the handles.
Mesa will use this.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 61 +
drivers/gpu/drm/amd/amdgpu
From: Marek Olšák
For amdgpu.
drm_syncobj_create is renamed to drm_syncobj_create_as_handle, and new
helpers drm_syncobj_create and drm_syncobj_get_handle are added.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/drm_syncobj.c | 49 +++
include/drm
From: Marek Olšák
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/drm_syncobj.c | 33 +++--
include/drm/drm_syncobj.h | 1 +
2 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index
From: Marek Olšák
---
amdgpu/amdgpu.h| 30 ++
amdgpu/amdgpu_cs.c | 20
2 files changed, 50 insertions(+)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 238b1aa..b44b9b6 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1383,6
From: Marek Olšák
---
amdgpu/amdgpu.h | 14 ++
amdgpu/amdgpu_cs.c | 22 ++
include/drm/amdgpu_drm.h | 21 +
3 files changed, 57 insertions(+)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 979acfc..23cde10 100644
--- a
From: Marek Olšák
---
include/drm/drm.h | 24
xf86drm.c | 22 ++
xf86drm.h | 3 +++
3 files changed, 49 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index bf3674a..4da1667 100644
--- a/include/drm/drm.h
+++ b
From: Marek Olšák
---
amdgpu/amdgpu.h| 20
amdgpu/amdgpu_cs.c | 12
2 files changed, 32 insertions(+)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index b44b9b6..979acfc 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1354,6 +1354,26 @@ int
On Wed, Sep 13, 2017 at 5:03 AM, zhoucm1 wrote:
> Hi Marek,
>
> You're doing same things with me, see my "introduce syncfile as fence
> reuturn" patch set, which makes things more simple, we just need to directly
> return syncfile fd to UMD when CS, then the fence UMD get will be always
> syncfile
On Wed, Sep 13, 2017 at 1:32 PM, Zhou, David(ChunMing)
wrote:
> Could you describe how difficult to directly use CS syncfile fd in Mesa
> compared with concerting CS seq to syncfile fd via several syncobj ioctls?
It just simplifies things. Mesa primarily uses seq_no-based fences and
will continue
On Wed, Sep 13, 2017 at 3:46 PM, Zhou, David(ChunMing)
wrote:
> For android using mesa instance, egl draw will dequeue an android buffer,
> after egl draw, the buffer will back to android bufffer queue, but need
> append a syncfile fd. If getting syncfile fd for every egl draw always needs
> sever
Reviewed-by: Marek Olšák
Marek
On Mon, Sep 11, 2017 at 5:43 PM, Jean Delvare wrote:
> Several users have complained that the tile table update broke Oland
> support. Despite several attempts to fix it, the root cause is still
> unknown at this point and no solution is available. As
Can I get Rb for this series?
Thanks,
Marek
On Tue, Sep 12, 2017 at 10:42 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> for being able to convert an amdgpu fence into one of the handles.
> Mesa will use this.
>
> Signed-off-by: Marek Olšák
> ---
> drivers/gpu
On Thu, Sep 14, 2017 at 10:01 AM, Emil Velikov wrote:
> On 14 September 2017 at 08:56, Emil Velikov wrote:
>> Hi Marek,
>>
>> On 12 September 2017 at 21:42, Marek Olšák wrote:
>>
>>> include/drm/drm_syncobj.h | 4
>> Pleas
On Fri, Sep 29, 2017 at 1:42 AM, Dave Airlie wrote:
> On 29 September 2017 at 06:41, Marek Olšák wrote:
>> Can I get Rb for this series?
>>
>
> For the series,
>
> Reviewed-by: Dave Airlie
>
> Alex, please merge the two drm core precursor with patch 3.
Alex, th
On Fri, Sep 29, 2017 at 4:44 AM, Chunming Zhou wrote:
>
>
> On 2017年09月13日 04:42, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> For amdgpu.
>>
>> drm_syncobj_create is renamed to drm_syncobj_create_as_handle, and new
>> helpers drm_
On Fri, Sep 29, 2017 at 4:13 PM, Marek Olšák wrote:
> On Fri, Sep 29, 2017 at 4:44 AM, Chunming Zhou wrote:
>>
>>
>> On 2017年09月13日 04:42, Marek Olšák wrote:
>>>
>>> From: Marek Olšák
>>>
>>> For amdgpu.
>>>
>>> drm_syn
available rings
tests/amdgpu: execute const fill on all the available rings
tests/amdgpu: execute copy linear on all the available rings
Marek Olšák (2):
amdgpu: add amdgpu_query_sw_info for querying high bits of 32-bit address
space
configure.ac: bump version to 2.4.90
Michel
For the series:
Reviewed-by: Marek Olšák
Marek
On Mon, Feb 26, 2018 at 2:16 PM, Christian König
wrote:
> Return high addresses if requested and available.
>
> Signed-off-by: Christian König
> ---
> amdgpu/amdgpu.h | 1 +
> amdgpu/amdgpu_device.c |
On Sun, Jul 16, 2017 at 11:36 PM, Dave Airlie wrote:
>>
>> I can take a look at it, I just won't have time until next week most likely.
>
> I've taken a look, and it's seemingly more complicated than I'm
> expecting I'd want to land in Mesa before 17.2 ships, I'd really
> prefer to just push the n
Hi Dave,
If you just add "get" functions for what you need from amdgpu objects,
that should be fine.
Marek
On Mon, Jul 17, 2017 at 11:00 PM, Dave Airlie wrote:
> On 18 July 2017 at 03:02, Christian König wrote:
>> Am 17.07.2017 um 05:36 schrieb Dave Airlie:
I can take a look at it, I
Reviewed-by: Marek Olšák
Marek
On Sun, Jul 30, 2017 at 10:18 AM, Jean Delvare wrote:
> As I was staring at the si_init_golden_registers code, I noticed that
> the Pitcairn initialization silently falls through the Cape Verde
> initialization, and the Oland initialization falls th
On Tue, Nov 14, 2017 at 8:10 PM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> Document the drm_syncobj_get_handle() function parameters.
>
> Cc: Marek Olšák
> Cc: Dave Airlie
> Cc: Alex Deucher
> Cc: Daniel Vetter
> Suggested-by: Daniel Vetter
>
int p = -1.
unsigned u = p;
int p2 = u;
p2 is -1.
Marek
On Tue, Jan 9, 2024, 03:26 Christian König wrote:
> Am 09.01.24 um 09:09 schrieb 李真能:
>
> Thanks!
>
> What about the second patch?
>
> The second patch: amdgpu: change proirity value to be consistent with
> kernel.
>
> As I want to pass
New libdrm has been released.
Marek Olšák (2):
amdgpu: add amdgpu_va_get_start_addr
meson: bump libdrm version to 2.4.119
git tag: libdrm-2.4.119
https://dri.freedesktop.org/libdrm/libdrm-2.4.119.tar.xz
SHA256: 0a49f12f09b5b6e68eaaaff3f02ca7cff9aa926939b212d343161d3e8ac56291
libdrm
amdgpu: Make amdgpu_cs_signal_semaphore() thread-safe
Marek Olšák (2):
amdgpu: sync amdgpu_drm.h
Bump version to 2.4.121
Matt Turner (2):
symbols-check: Add _GLOBAL_OFFSET_TABLE_
symbols-check: Add _fbss, _fdata, _ftext
Pierre-Eric Pelloux-Prayer (5):
Hi Thomas,
Commit 9eac534db0013aff9b9124985dab114600df9081 as per the title
breaks (crashes?) lightdm (login screen) such that all I get is the
terminal. It's also reproducible with tag v6.9 where the commit is
present.
Reverting the commit fixes lightdm. A workaround is to bypass lightdm
by trig
+amd-gfx
On Thu, Jun 13, 2024 at 1:59 AM Marek Olšák wrote:
>
> Hi Thomas,
>
> Commit 9eac534db0013aff9b9124985dab114600df9081 as per the title
> breaks (crashes?) lightdm (login screen) such that all I get is the
> terminal. It's also reproducible with tag v6.9 where
On Thu, Jun 13, 2024 at 3:23 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 13.06.24 um 08:00 schrieb Marek Olšák:
> > +amd-gfx
> >
> > On Thu, Jun 13, 2024 at 1:59 AM Marek Olšák wrote:
> >> Hi Thomas,
> >>
> >> Commit 9eac534db0013aff9b912
I think the problem with Radeon/TTM is much deeper. Let me demonstrate
it on the following example.
Unigine Heaven needs about 385MB of space for static resources, that's
only 75% of my 512MB card. Yet, TTM is not capable of getting all of
that into VRAM. If I allow GTT placements, I get 20 fps, w
On Thu, Nov 29, 2012 at 12:44 AM, Alan Swanson wrote:
> On Wed, 2012-11-28 at 18:24 -0500, Jerome Glisse wrote:
>> On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom
>> wrote:
>> > On 11/28/2012 04:58 PM, j.glisse at gmail.com wrote:
>> >>
>> >> From: Jerome Glisse
>> >>
>> >> This patch add a m
On Thu, Nov 29, 2012 at 9:04 AM, Thomas Hellstrom
wrote:
> On 11/29/2012 03:15 AM, Marek Ol??k wrote:
>>
>> On Thu, Nov 29, 2012 at 12:44 AM, Alan Swanson wrote:
>>>
>>> On Wed, 2012-11-28 at 18:24 -0500, Jerome Glisse wrote:
On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom
wrot
On Thu, Nov 29, 2012 at 10:18 AM, Thomas Hellstrom
wrote:
> On 11/28/2012 10:51 PM, Marek Ol??k wrote:
>>
>> I think the problem with Radeon/TTM is much deeper. Let me demonstrate
>> it on the following example.
>>
>> Unigine Heaven needs about 385MB of space for static resources, that's
>> only
On Thu, Nov 29, 2012 at 9:33 PM, Thomas Hellstrom
wrote:
> On 11/29/2012 01:52 PM, Marek Ol??k wrote:
>>
>> On Thu, Nov 29, 2012 at 9:04 AM, Thomas Hellstrom
>> wrote:
>>>
>>> On 11/29/2012 03:15 AM, Marek Ol??k wrote:
On Thu, Nov 29, 2012 at 12:44 AM, Alan Swanson
wrote:
>
>
On Thu, Nov 29, 2012 at 4:35 PM, wrote:
> So as a followup is 2 patch. The first one just stop trying to move
> object at each cs ioctl i believe it could be included in 3.7 as it
> improve performances (especialy with vram change from userspace).
>
> The second one implement a vram eviction poli
---
radeon/radeon_surface.c |2 --
1 file changed, 2 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 03b1c5d..c62cbf9 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -797,7 +797,6 @@ static int eg_surface_init(struct radeon_surface_manag
This allows texturing with depth-stencil buffers directly without the copy
to CB. The separate miptree description for stencil is added, because
the stencil mipmap offsets are not really depth offsets/4 (at least
for the texture units).
---
radeon/radeon_surface.c | 197 ++
The calculation led to the number 8192, which is too high.
---
radeon/radeon_surface.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 66c2444..eb587d2 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -939,6 +939
In this specific case, the eg_surface_sanity function (or something
like that, I don't remember its name) returns an error. Then the
cascade of perfectly working fail codepaths propagate the error to the
OpenGL user as an unsupported framebuffer object setup.
Marek
On Tue, Oct 16, 2012 at 8:50 AM
d too.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/radeon/r100.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 3ae51ad..e40dbdc 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gp
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
I think the problem with Radeon/TTM is much deeper. Let me demonstrate
it on the following example.
Unigine Heaven needs about 385MB of space for static resources, that's
only 75% of my 512MB card. Yet, TTM is not capable of getting all of
that into VRAM. If I allow GTT placements, I get 20 fps, w
On Thu, Nov 29, 2012 at 12:44 AM, Alan Swanson wrote:
> On Wed, 2012-11-28 at 18:24 -0500, Jerome Glisse wrote:
>> On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom
>> wrote:
>> > On 11/28/2012 04:58 PM, j.gli...@gmail.com wrote:
>> >>
>> >> From: Jerome Glisse
>> >>
>> >> This patch add a mini
On Thu, Nov 29, 2012 at 9:04 AM, Thomas Hellstrom wrote:
> On 11/29/2012 03:15 AM, Marek Olšák wrote:
>>
>> On Thu, Nov 29, 2012 at 12:44 AM, Alan Swanson wrote:
>>>
>>> On Wed, 2012-11-28 at 18:24 -0500, Jerome Glisse wrote:
>>>>
>>&
On Thu, Nov 29, 2012 at 10:18 AM, Thomas Hellstrom wrote:
> On 11/28/2012 10:51 PM, Marek Olšák wrote:
>>
>> I think the problem with Radeon/TTM is much deeper. Let me demonstrate
>> it on the following example.
>>
>> Unigine Heaven needs about 385MB of space for
On Thu, Nov 29, 2012 at 9:33 PM, Thomas Hellstrom wrote:
> On 11/29/2012 01:52 PM, Marek Olšák wrote:
>>
>> On Thu, Nov 29, 2012 at 9:04 AM, Thomas Hellstrom
>> wrote:
>>>
>>> On 11/29/2012 03:15 AM, Marek Olšák wrote:
>>>>
>>>
On Thu, Nov 29, 2012 at 4:35 PM, wrote:
> So as a followup is 2 patch. The first one just stop trying to move
> object at each cs ioctl i believe it could be included in 3.7 as it
> improve performances (especialy with vram change from userspace).
>
> The second one implement a vram eviction poli
No version bump is required because setting the flag on older DRM has
no effect.
This only reserves the bit and doesn't use it. I assume we will use it
for buffer eviction heuristics.
Signed-off-by: Marek Olšák
---
include/uapi/drm/radeon_drm.h |1 +
1 file changed, 1 insertion(+)
For the series:
Reviewed-by: Marek Olšák
Marek
On Thu, Jan 3, 2013 at 12:27 AM, Ilija Hadzic
wrote:
> length_dw field was assigned twice. While at it, move user_ptr
> assignment together with all other assignments to p->chunks[i]
> structure to make the code more readable.
>
On Tue, Jan 8, 2013 at 12:09 AM, Ilija Hadzic
wrote:
>
>
> On Fri, 4 Jan 2013, Alex Deucher wrote:
>
>> R6xx and r7xx are really all you need to worry about in this case.
>> R1xx-r5xx UMS uses a different kernel interface for command submission
>> and evergreen and later don't have UMS drm support
Probably not a candidate for stable kernels because of conflicts
in DRM versioning.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/radeon/radeon_drv.c |3 ++-
drivers/gpu/drm/radeon/reg_srcs/rv515 |2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
nges since commit 7b4cf994e4c6ba48872bb25253cc393b7fb74c82:
>>
>> udldrmfb: udl_get_edid: drop unneeded i-- (2013-01-14 08:45:27 +1000)
>>
>> are available in the git repository at:
>> git://people.freedesktop.org/~agd5f/linux drm-fixes-3.8
>>
>> Alex Deuc
: Fix build failure in test_decode.c
Marek Olšák (6):
radeon: simplify ZS buffer checking on r600
radeon: optimize allocation for depth w/o stencil and stencil
w/o depth on EG
radeon: force 2D tiling for MSAA surfaces
radeon: tweak TILE_SPLIT for MSAA surfaces
tests/m
about that.
Marek
On Sun, Aug 12, 2012 at 10:09 AM, Andreas Radke wrote:
> Am Sat, 11 Aug 2012 21:25:04 +0200
> schrieb Marek Olšák :
>
>> git tag: libdrm-2.4.38
>>
>> http://dri.freedesktop.org/www/libdrm/libdrm-2.4.38.tar.bz2
>> MD5: 8018e0bce5059cee05d8
MSAA is impossible without them.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/radeon/r600_cs.c | 94 +-
drivers/gpu/drm/radeon/r600d.h | 17 ++
drivers/gpu/drm/radeon/radeon_drv.c |3 +-
drivers/gpu/drm/radeon/reg_srcs/r600 |8 ---
4
---
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 892dca6..98f4aaf 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -165,7 +165,7 @@ static void surf_minify(struct radeon_s
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/radeon/r600_cs.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 1bec5b8..ab74e6b 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers
Please can someone tell me if this patch will end up in kernel 3.6 or 3.7.
If it is merged in Linus's tree in the coming days, I'll try to
complete R600-R700 MSAA support (and therefore GL3.0) for Mesa 9.0.
Marek
On Sun, Aug 19, 2012 at 2:22 AM, Marek Olšák wrote:
> MSAA is impos
On Mon, Aug 20, 2012 at 7:35 AM, Paul Menzel
wrote:
> Dear Marek,
>
>
> thank you for all your work on MSAA.
>
>
> Am Sonntag, den 19.08.2012, 21:23 +0200 schrieb Marek Olšák:
>
> Unfortunately you do not provide any commit message. What is the problem
> and what
I am not sure whether this is needed, but better be safe than sorry.
---
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 98f4aaf..4118a37 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/radeon/r600_cs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index ab74e6b..7799e28 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm
This should help catch uninitialized registers and reject commands
because of that.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/radeon/r600_cs.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
rejected without this
fix on r600.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/radeon/r600_cs.c | 19 +--
drivers/gpu/drm/radeon/r600d.h |8
drivers/gpu/drm/radeon/radeon_drv.c |3 ++-
drivers/gpu/drm/radeon/reg_srcs/r600 |1 -
4 files changed, 27
Dave Airlie (1):
radeon: add prime import/export support
Kenneth Graunke (1):
intel: Use VG_CLEAR on the context destroy ioctl as well.
Marek Olšák (3):
radeon: fix allocation of MSAA surfaces on r600-r700
radeon: align r600 msaa buffers to a multiple of macrotile size
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
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
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/gp
---
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
---
radeon/radeon_surface.c |2 --
1 file changed, 2 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 03b1c5d..c62cbf9 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -797,7 +797,6 @@ static int eg_surface_init(struct radeon_surface_manag
This allows texturing with depth-stencil buffers directly without the copy
to CB. The separate miptree description for stencil is added, because
the stencil mipmap offsets are not really depth offsets/4 (at least
for the texture units).
---
radeon/radeon_surface.c | 197 ++
The calculation led to the number 8192, which is too high.
---
radeon/radeon_surface.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 66c2444..eb587d2 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -939,6 +939
8:50 AM, Paul Menzel
wrote:
> Dear Marek,
>
>
> Am Dienstag, den 16.10.2012, 02:21 +0200 schrieb Marek Olšák:
>> The calculation led to the number 8192, which is too high.
>
> what is the reason it is limited to 4096? Hardware limitation?
>
> What are the ramific
øgsberg (1):
intel: Mark bo's exported to prime as not reusable
Marcin Slusarz (1):
libkms: link against libdrm
Marek Olšák (5):
radeon: don't take the stencil-specific codepath for buffers without
stencil
radeon: don't force stencil tile split to 0
On Tue, Oct 4, 2011 at 1:48 PM, Thomas Hellstrom wrote:
> Bah, I totally missed this patch and thus never reviewed it :( Probably on
> vacation.
>
> There are a couple of things I'd like to point out.
>
> 1) The bo subsystem may never assume that fence objects are ordered, so that
> when we unref
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom wrote:
> In any case, I'm not saying fences is the best way to flush but since the bo
> code assumes that signaling a sync object means "make the buffer contents
> available for CPU read / write", it's usually a good way to do it; there's
> even a s
On Fri, Oct 7, 2011 at 3:42 PM, Jerome Glisse wrote:
> Forget to mention that we would need a new wait_fence ioctl to wait
> for a specific fence seq on a specific ring
We need a wait_fence ioctl anyway and even with a timeout parameter.
It's a mandatory OpenGL feature. r600g uses a loop with sch
On Fri, Oct 7, 2011 at 3:38 PM, Jerome Glisse wrote:
> I should have look at the patch long ago ... anyway i think a better
> approach would be to expose fence id as 64bits unsigned to each
> userspace client. I was thinking of mapping a page readonly (same page
> as the one gpu write back) at som
On Fri, Oct 7, 2011 at 10:00 AM, Thomas Hellstrom wrote:
> OK. First I think we need to make a distinction: bo sync objects vs driver
> fences. The bo sync obj api is there to strictly provide functionality that
> the ttm bo subsystem is using, and that follows a simple set of rules:
>
> 1) the bo
t;>
>>>> On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hellstrom wrote:
>>>>
>>>>
>>>>>
>>>>> Oh, and one more style comment below:
>>>>>
>>>>> On 08/07/2011 10:39 PM, Marek Olšák wrote:
>>
Hi Thomas,
I have made no progress so far due to lack of time.
Would you mind if I fixed the most important things first, which are:
- sync objects are not ordered, (A)
- every sync object must have its corresponding sync_obj_arg, (B)
and if I fixed (C) some time later.
I planned on moving the t
driver-specific way and you have the benefit of assuming that they are
> ordered.
>
> Since the new functionality is a performance improvement, If time is an
> issue, I suggest we back this change out and go for the next merge window.
>
> /Thomas
>
>
> On 10/24/2011 07:10 PM
the registers.
So let's just use what we have in the registers.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/radeon/evergreen_cs.c | 92 +---
drivers/gpu/drm/radeon/r300.c | 94 ++---
drivers/gpu/drm/radeon/r600
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 nee
People can start using transform feedback on r6xx with this.
Strict CS checking will be implemented later.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/radeon/evergreen_cs.c | 104 +++--
drivers/gpu/drm/radeon/evergreend.h | 10 +++
drivers/gpu/drm/radeon
201 - 300 of 554 matches
Mail list logo
