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
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
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
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
-
Dammit. I renamed the RADEON_INFO definitions for the new queries to
0xd, e, f in the kernel tree, but I forgot to update the Mesa code,
which used 0xc, d, e. Sorry.
Marek
On Wed, Feb 26, 2014 at 7:26 PM, Christian K?nig
wrote:
> Am 26.02.2014 18:56, schrieb Marek Ol??k:
>
>> On Mon, Feb 24, 201
From: Marek Ol??k
Needed by userspace for HTILE buffer size calculations.
Signed-off-by: Marek Ol??k
---
It returns 2 on Bonaire. I hope it's correct.
drivers/gpu/drm/radeon/cik.c| 7 ++-
drivers/gpu/drm/radeon/radeon_kms.c | 9 +
drivers/gpu/drm/radeon/si.c | 7 +
From: Marek Ol??k
Only the render backends of the first shader engine were enabled. The others
were erroneously disabled. Enabling the other render backends improves
performance a lot.
Unigine Sanctuary on Bonaire:
Before: 15 fps
After: 90 fps
Judging from the fan noise, the GPU was also u
From: Marek Ol??k
This will allow userspace to correctly program the PA_SC_RASTER_CONFIG
register, so it can be considered a fix.
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/cik.c| 2 ++
drivers/gpu/drm/radeon/radeon.h | 4 ++--
drivers/gpu/drm/radeon/radeon_kms.c | 9 +++
From: Marek Ol??k
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/atombios_crtc.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index b197059..ec97bad 100644
--- a/d
From: Marek Ol??k
We don't have the NUM_BANKS parameter, so we have to calculate it
from the other parameters. NUM_BANKS is not constant on CIK.
This fixes 2D tiling for the display engine on CIK.
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/atombios_crtc.c | 64 +
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.
>
> Signed-off-by: I
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/rade
This might be responsible for the bad r300g MSAA performance results
on Phoronix. I have no other explanation.
There is an optimization in r300g which forces the VRAM domain for
non-staging CB and DB only. Other than that, VRAM|GTT is the default
for all textures and GTT is the default for all buf
On Fri, Dec 27, 2013 at 9:27 PM, Keith Packard wrote:
> Marek Ol??k writes:
>
>> 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.
>
> It's either that or plan on moving DRI2
From: Marek Ol??k
This fixes a bug which was causing rejections of valid GPU commands
from userspace.
Signed-off-by: Marek Ol??k
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/evergreen_cs.c | 5 -
drivers/gpu/drm/radeon/r600_cs.c | 5 -
2 files changed, 8 insertions(+),
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
libdrm 2.4.40 has been released.
The reason is we need to use the radeon stencil mipmap allocator for combined
depth-stencil buffers in Mesa.
Alex Deucher (1):
radeon: add some new SI pci ids
Andreas Boll (1):
radeon: fix unused-fu
I will release a new version of libdrm after this is committed.
---
radeon/radeon_surface.c |9 ++---
radeon/radeon_surface.h |1 +
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 288b5e2..56012da 100644
--- a/radeo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A new version of libdrm has been released. The main motivation for this
release is the changes in the radeon surface allocator, which helps fix
multisample textures on the Radeon Cayman family chipsets.
Alex Deucher (4):
radeon: add new SI pci i
From: Michel D?nzer
Signed-off-by: Marek Ol??k
---
radeon/radeon_surface.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index d5c45c4..56e2e4a 100644
--- a/radeon/radeon_surface.c
+++ b/radeon
From: Michel D?nzer
Bug fixes and simplification by Marek.
We have to use the tile index of 0 for non-MSAA depth-stencil after all.
Signed-off-by: Marek Ol??k
---
include/drm/radeon_drm.h | 11 +
radeon/radeon_surface.c | 620 ++-
radeon/radeon_sur
From: Michel D?nzer
Signed-off-by: Marek Ol??k
---
radeon/radeon_surface.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 927a21e..cd5cbd6 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -143
Having patches on a mailing list is good enough, but generally if
people *trust* you that you will have an open userspace, that's good
enough too if you have people's trust.
In my opinion, the required kernel code must land in Linus's tree
first. If it's not there, it's like it didn't exist at all
Reviewed-by: Marek Ol??k
Marek
On Fri, Nov 22, 2013 at 5:20 AM, Keith Packard wrote:
> Upper levels of the stack use base.stamp to tell when a drawable needs to be
> revalidated, but the dri state tracker was using dPriv->lastStamp. Those two,
> along with dri2.stamp, all get simultaneously inc
Sorry, the autorship of the other patch changed when I moved the hunk
there and didn't notice it. :(
Marek
On Mon, Nov 18, 2013 at 10:29 AM, Michel D?nzer wrote:
> On Fre, 2013-11-15 at 18:55 +0100, Marek Ol??k wrote:
>> From: Michel D?nzer
>>
>> Signed-off-by: Marek Ol??k
>
> [...]
>
>> @@ -1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A new version of libdrm has been released. It adds support for 2D tiling for
Sea Islands Radeon GPUs and fixes bugs.
Ian Romanick (1):
intel: Use memset instead of VG_CLEAR
Marek Ol??k (3):
radeon: implement 2D tiling for CIK
rade
Ping
On Wed, Apr 29, 2015 at 7:40 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Userspace will be able to tell whether a GPU reset occured by comparing
> an old referece value of the counter with a new value.
>
> Signed-off-by: Marek Olšák
> ---
> drivers/gpu/drm/radeon/radeon.h
On Tue, Jun 9, 2015 at 4:51 AM, Alex Deucher wrote:
> On Fri, Jun 5, 2015 at 2:57 PM, Jerome Glisse wrote:
>> On Tue, May 26, 2015 at 11:19:31PM -0400, Alex Deucher wrote:
>>> This header defines the ioctl interface to the driver.
>>>
>>> v2: remove stale tiling defines
>>> v3: add appropriate pa
Reviewed-by: Marek Olšák
Marek
On Sun, Sep 6, 2015 at 6:38 PM, Alan Coopersmith
wrote:
> Fixes "error: implicit declaration of function 'alloca'" failures
> when building on Solaris
>
> Signed-off-by: Alan Coopersmith
> ---
> amdgpu/amdgpu_cs.c |3 +++
> tests/amdgpu/basic_tests
There are a few useful prerequisites for contributing to Mesa and
being efficient:
1) Know OpenGL and GLSL
Tutorials: http://ogldev.atspace.co.uk/
You need to know the API one way or another. Eventually, you want to
switch to the official OpenGL, GLSL, and extension specifications as
your primary
Tested-by: Marek Olšák
Tested with: RV670, RV730, Redwood, Cayman, Cape Verde, Bonaire, Hawaii.
I have Mesa patches for the temperature, clocks, and GPU load. All
exposed via the Gallium HUD.
Marek
On Wed, Oct 1, 2014 at 5:38 PM, Alex Deucher wrote:
> This patch set implements a number of n
I have just discovered that WAIT_UNTIL=WAIT_3D_IDLE must be set before using
CP DMA.
Marek
On Thu, Jul 11, 2013 at 9:35 PM, wrote:
> From: Alex Deucher
>
> Lighter weight than using the 3D engine.
>
> v2: fix ring count
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/r600.c
On Fri, Apr 24, 2015 at 9:43 AM, Zhou, Jammy wrote:
> Hi Alex,
>
> For the core driver patch:
>
> +config DRM_AMDGPU
> + tristate "AMD GPU"
> + depends on DRM && PCI
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + select FW_
Hi Alex,
He sent them to me. I've applied them to my tree:
http://cgit.freedesktop.org/~mareko/mesa/log/?h=amdgpu
Marek
On Fri, Apr 24, 2015 at 5:38 PM, Alex Deucher wrote:
> On Thu, Apr 23, 2015 at 11:53 AM, Christian König
> wrote:
>> From: Christian König
>>
>> Remove the mostly unused
From: Marek Olšák
Userspace will be able to tell whether a GPU reset occured by comparing
an old referece value of the counter with a new value.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_device.c | 2 ++
drivers/gpu/drm/radeo
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/evergreen_cs.c |2 +-
drivers/gpu/drm/radeon/radeon_drv.c |3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index d8f5d5f..a759a3d 10
The MIP_ADDRESS state has 2 meanings. If the texture has one sample
per pixel, it's a pointer to the mipmap chain. If the texture has
multiple samples per pixel, it's a pointer to FMASK, a metadata buffer
needed for reading compressed MSAA textures. AFAIK, the mipmap
alignment rules do not apply to
Reviewed-by: Marek Olšák
BTW, we don't have to define everything here. We can use most of the
32 values freely.
Marek
On Fri, Oct 25, 2024 at 2:03 AM Qiang Yu wrote:
>
> From: Qiang Yu
>
> This is used when radeonsi export small texture's modifier
> to user with eglE
On Mon, Dec 16, 2024 at 4:27 AM Michel Dänzer
wrote:
> On 2024-12-15 21:53, Marek Olšák wrote:
> > The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
> >
> > Signed-off-by: Marek Olšák marek.ol...@amd.com>>
> >
> > diff --git a/include/uap
On Mon, Dec 16, 2024 at 5:46 AM Lucas Stach wrote:
> Am Montag, dem 16.12.2024 um 10:27 +0100 schrieb Michel Dänzer:
> > On 2024-12-15 21:53, Marek Olšák wrote:
> > > The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
> > >
> > > Signed-off-
On Mon, Dec 16, 2024 at 9:53 AM Simona Vetter
wrote:
> On Mon, Dec 16, 2024 at 11:46:13AM +0100, Lucas Stach wrote:
> > Am Montag, dem 16.12.2024 um 10:27 +0100 schrieb Michel Dänzer:
> > > On 2024-12-15 21:53, Marek Olšák wrote:
> > > > The com
Missed 2 lines from the diff:
+#define DRM_FORMAT_MOD_LINEAR_PITCH_ALIGN_128B fourcc_mod_code(NONE, 2)
+#define DRM_FORMAT_MOD_LINEAR_PITCH_ALIGN_256B fourcc_mod_code(NONE, 3)
Marek
On Sun, Dec 15, 2024 at 3:53 PM Marek Olšák wrote:
> The comment explains the problem w
The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
Signed-off-by: Marek Olšák
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 78abd819fd62e..8ec4163429014 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -484,9 +484,27
On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey wrote:
> On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
> >
> > For that reason I think linear modifiers with explicit pitch/size
> > alignment constraints is a sound concept and fits into how modifiers work
> > overall.
> > -Sima
>
>
On Thu, Dec 19, 2024 at 5:32 AM Brian Starkey wrote:
> On Wed, Dec 18, 2024 at 09:53:56PM +0000, Marek Olšák wrote:
> > On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey
> wrote:
> >
> > > On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
> > > >
>
> * Modifiers must uniquely encode buffer layout. In other words, a buffer
> must
> * match only a single modifier.
>
That sentence is misleading and impossible to meet. Specifications are
sometimes changed to reflect the overwhelming reality. Multiple modifiers
can represent identical layouts
15, 2025 at 12:20:07PM +, Daniel Stone wrote:
> > On Wed, 15 Jan 2025 at 04:05, Marek Olšák wrote:
> > > On Tue, Jan 14, 2025 at 12:58 PM Daniel Stone
> wrote:
> > >> AMD hardware is the only hardware I know of which doesn't support
> > >> overalig
On Mon, Jan 20, 2025 at 1:41 PM Simona Vetter
wrote:
> On Mon, Jan 20, 2025 at 08:58:20AM +0100, Thomas Zimmermann wrote:
> > Hi
> >
> >
> > Am 18.01.25 um 03:37 schrieb Marek Olšák:
> > [...]
> > >
> > > 3) Implementing DRM_FORMAT_MOD_LINEAR as
I would keep the existing modifier interfaces, API extensions, and
expectations the same as today for simplicity.
The new linear modifier definition (proposal) will have these fields:
5 bits for log2 pitch alignment in bytes
5 bits for log2 height alignment in rows
5 bits for log2 offset
On Fri, Dec 20, 2024 at 10:24 AM Simona Vetter
wrote:
> On Thu, Dec 19, 2024 at 05:09:33PM +0100, Michel Dänzer wrote:
> > On 2024-12-19 10:02, Daniel Stone wrote:
> > >
> > > How this would be used in practice is also way too underdocumented. We
> > > need to document that exact-round-up 64b is
On Tue, Jan 14, 2025 at 1:34 PM Faith Ekstrand wrote:
> On January 14, 2025 03:39:45 Marek Olšák wrote:
>
>> I would keep the existing modifier interfaces, API extensions, and
>> expectations the same as today for simplicity.
>>
>> The new linear modifier definit
On Tue, Jan 14, 2025 at 12:55 PM James Jones wrote:
> I don't see how that fits in the current modifier usage patterns. I'm
> not clear how applications are supposed to programmatically "look at the
> modifiers of other drivers to find commonalities," nor how that "keeps
> "expectations the same
On Tue, Jan 14, 2025 at 12:58 PM Daniel Stone wrote:
> Hi,
>
> On Tue, 14 Jan 2025 at 09:38, Marek Olšák wrote:
> > I would keep the existing modifier interfaces, API extensions, and
> expectations the same as today for simplicity.
>
> Well yes, not just for simplicity
USHRT_MAX seems too low. Traces for workstation apps create 20-30k BOs,
which is not very far from the limit. RADV doesn't suballocate BOs. Neither
GL nor VK has a ilmit on the number of BOs that can be created. The
hypothetical maximum number of BOs that can be allocated on a GPU with 32GB
of addr
501 - 554 of 554 matches
Mail list logo
