[Mesa-dev] Has anyone stressed radeonsi memory?

[Matias N. Goldberg]

Hi!

> Are you using the amdgpu kernel driver from an amdgpu-pro release or
> from the upstream Linux kernel? (If you're not sure, provide the dmesg
> output and Xorg log file)

> If the latter, can you try a 4.13 or 4.14 kernel and see if that works
> better?


I'm using upstream Linux kernel (without my distro's patches), with amdgpu (not pro).

I could try newer kernels.

> Why, doesn't your distro have LLVM development packages?
They aren't as up to date. Keeping up-to-date with everything mesa needs is exhausting.
I started compiling LLVM from source when I needed to test an LLVM patch to fix a GLSL shader compiler bug.

I also compile mesa from source (rather thank using Oibaf or Padoka's PPA for Ubuntu) because as a graphics dev, being able to debug inside Mesa has proven to be an invaluable tool.


So I take it from your questions, that this behavior I saw isn't exactly "normal" or "expected" and I should dedicate some time to see if I can repro in newer versions, and if possible create a small repro.

Thanks,

Cheers
Matias
________________________________
De: Michel Dänzer <michel at daenzer.net>
Para: Matias N. Goldberg <dark_sylinc at yahoo.com.ar> 
CC: ML Mesa-dev <mesa-dev at lists.freedesktop.org>
Enviado: Martes, 14 de noviembre, 2017 14:43:28
Asunto: Re: [Mesa-dev] Has anyone stressed radeonsi memory?



On 13/11/17 04:39 AM, Matias N. Goldberg wrote:
> 
> I am on a Radeon RX 560 2GB; using mesa git-57c8ead0cd (So... not too new not too old), Kernel 4.12.10
> 
> I've been having complaints about our WIP branch of Ogre 2.2 about out of memory crashes, and I fixed them.
> 
> I made a stress test where 495 textures with very different resolutions (most of them not power-of-2), and total memory from those textures is around 700MB (for some reason radentop reports all 2GB of my card are used during this stress test).
> Additionally, 495 cubes (one cube for each texture) are rendered to screen to ensure driver keeps them resident.
> 
> The problem is, we have different strategies:
> 1. In one extreme, we can load every texture to a staging region, one at a time; and then from staging region copy to the final texture.
> 2. In the other extreme, we load all textures to RAM at once, and use one giant staging region.
> 
> Loading everything at once causes a GL_OUT_OF_MEMORY while creating the staging area of 700MB. Ok... sounds sorta reasonable.
> 
> But things get interesting when loading using a staging area of 512MB:
> 1. Loading goes fine.
> 2. For a time, everything works fine.
> 3. If I hide all cubes so that they aren't shown anymore:
>     1. Framerate usually goes way down (not always), like 8 fps or so (should be at 1000 fps while empty, around 200 fps while showing the cubes).
> How slow it becomes is not consistent.    2. radeontop shows consumption goes down a lot (like half or more).
>     3. A few seconds later, I almost always get a crash (SIGBUS) while writing to an UBO buffer that had been persistently mapped (non-coherent) since the beginning of the application.
>     4. Running through valgrind, I don't get a crash.
>     5. There are no errors reported by OpenGL.
> 4. I don't get a crash if I never hide the cubes.
> 
> Using a smaller staging area (256MB or lower) everything is always fine.
> 
> So... is this behavior expected?
> Am I uncovering a weird bug in how radeonsi/amdgpu-pro handle memory pages?

Are you using the amdgpu kernel driver from an amdgpu-pro release or
from the upstream Linux kernel? (If you're not sure, provide the dmesg
output and Xorg log file)

If the latter, can you try a 4.13 or 4.14 kernel and see if that works
better?



> I'd normally update to latest git, then create a test if the problem persists; but I've pulled latest git and saw that it required me to recompile llvm as well...

Why, doesn't your distro have LLVM development packages?


-- 
Earthling Michel Dänzer               |              http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
mesa-dev mailing list
mesa-dev at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev