After learning about this thread, RPI4 on Libreelec 9.1.502 thumbnail/pictures problems
This raises the question of how to check if the values set for GPU_MEM and CMA are valid.
After learning about this thread, RPI4 on Libreelec 9.1.502 thumbnail/pictures problems
This raises the question of how to check if the values set for GPU_MEM and CMA are valid.
If you are using LE10 then don't worry about them. If you are on LE9.2 you shouldn't worry about them because you'll need to update to LE10 eventually
If you are using LE10 then don't worry about them. If you are on LE9.2 you shouldn't worry about them because you'll need to update to LE10 eventually
From what you said, it looks like it's been resolved in LE10?But When I updated RPI4 to LE10 (LibreELEC-RPi4.arm-9.95.1.img.gz),the same question comes up:
If you run LE 10 then leave gpu_mem at the default (76MB). It's only needed for H.264 hardware decoding. Setting it higher just wastes memory.
so long,
Hias
If you run LE 10 then leave gpu_mem at the default (76MB). It's only needed for H.264 hardware decoding. Setting it higher just wastes memory.
so long,
Hias
Does LE10 dynamically adjust GPU_MEM?Not sure if the video plugin will be used on the GPU (according to the Netflix plugin, it probably won't), so I hope it can be adjusted dynamically.
In addition, stopping a docker container will cause a LE10 restart. Does this have anything to do with the fact that the GPU_MEM setting is still high?For now, though, the default is still 76.
Video decoders and the graphics driver now use CMA memory which can be shared by other (userspace) programs.
By default we use 512MB CMA, previously we used 384MB but that was not enough to handle all 4k HEVC files. This can be tweaked with the cma dtoverlay - but keep in mind that if you reduce CMA memory you risk running into video decoder / graphics issues.
No idea about docker, best you open a separate thread about it or discuss in the thread you linked.
so long,
Hias
Thank you for your professional reply.
If I do the alignment of the CMA Dtoverlay, where exactly do I do it?The config. TXT?What are the specific command?
Yes, /flash/config.txt is the correct place for it. Add a line with eg "dtoverlay=cma,cma-384" at the end of the file to reduce CMA memory size to 384MB. See the README in /flash/overlays for more info about syntax and allowed options.
so long,
Hias
Yes, /flash/config.txt is the correct place for it.
Even on LE 10 Beta?
Even on LE 10 Beta?
yes, config.txt is still the place to configure overlays and bootloader/firmware specific settings.
so long,
Hias
To provide more context (for posterity & Google Search reasons), the following information might be helpful for providing more of the engineering details & context for why `gpu_mem is no longer as useful for the Raspberry Pi 4 as it was for previous RPi models:
Display MoreSetting gpu_mem sets the amount of memory assigned to the VideoCore VPU (Vector Processing Unit). That is responsible for codecs, camera, legacy framebuffer, and the firmware GLES driver on Pi0-3. This region has to be in the bottom 1G of RAM.
On Pi4 the V3D block has an IOMMU, so it can access all of memory, and Linux deals with the allocation out of ARM memory. And when using either DRM/KMS driver (which is default on Pi4), the display buffers come out of the CMA (Contiguous Memory Allocator) heap. Again the CMA heap has to be in the bottom 1G of RAM.
Setting gpu_mem to insane figures gains nothing on a Pi4. Setting the combined value of gpu_mem and CMA to a value greater than 1G (minus a bit) will result in a system that won't boot.
It's all in the docs - https://www.raspberrypi.org/documentati ... /memory.md (ack that this has already been linked to)
Source: Raspberry Pi 4 8GB GPU Memory Split - 6by9's post
Display More... throw away any thoughts on it being even remotely similar to an Intel/Nvidia etc GPU.
The term GPU in OUR case refers to the vector/scaler CPU, the Quad CPU's, the 3D HW blocks, the ISP, the display HW blocks, CODEC blocks etc. Everything that isn't ARM.
The vector/scaler CPU (Its a twin core) can access the first 1GB of RAM, but really don't need that much memory. It controls the rest of the HW blocks - the ones that are not controlled by the ARM. So on older PI's almost all the HW blocks are controlled by the FIRMWARE running on the vector/scaler units. With the Pi4, the 3D is now controlled by the ARM - the so called FKMS driver. However the firmware still controls the display. In KMS, the ARM also handles the display, and with libcamera, the ISP as well is controlled by the ARM. As each of these HW blocks control is moved to the ARM over time, the vector/scaler units require less RAM, so the gpu_memory split can be lower.
A minimal headless system only needs about 16MB of RAM allocated to the 'gpu' - even on the older devices, because you are not using the 3D, is ISP etc.
Source: Raspberry Pi 4 8GB GPU Memory Split - jamesh's post
Hopefully this is helpful to surface this information for those interested.