When experimental GL Driver is enabled, large images are not displayed properly

[atuyosi]

Hi,

I tried experimental GL Driver with HDMI monitor (BenQ EW2430).

When using the display command (imagemagick utility), I got strange output. It occurs when the size of the image file is greater than the graphics display resolution.

For example: display resolution 1920x1080, image size 2448x2448

This problem also occurs in OpenCV 's imshow function.

Error messages from dmesg are bellow.

[   74.559662] vc4-drm soc:gpu: failed to allocate buffer with size 1089536
[   74.611080] vc4-drm soc:gpu: failed to allocate buffer with size 1056768
[   74.611145] vc4-drm soc:gpu: failed to allocate buffer with size 1056768
[   74.614598] [drm:vc4_validate_bin_cl [vc4]] *ERROR* 0x00000000: packet 112 (VC4_PACKET_TILE_BINNING_MODE_CONFIG) failed to validate
< skip there are same message seven times. >

model: Raspberry Pi 3B OS: Raspbian Jessie with PIXEL $ uname -a Linux raspberrypi 4.4.35-v7+ #931 SMP Sat Nov 26 13:05:09 GMT 2016 armv7l GNU/Linux

P.S.

I found this tracker via Raspberry Pi • View topic - New Open GL Driver, Bug report thread. I hope that this tracker is a suitable reporting place.

[jonasarrow]

This is an interesting case.

1. What is the memory size for the GPU (cma=xxxM@yyyM in cmdline.txt, the xxx is the interesting part). The dmesg errors are the result of too low gpu memory. Also in the dmesg output at the beginning is a line saying how much cma is reserved.
2. The texture unit supports textures (images) with a maximum resolution of 2048x2048 (which is fairly close to 1980). So failing at higher resolutions is somewhat expected. If we look at your screenshot, it looks like you see parts of the picture repeated. This is likely such an sampling failure. Of course, this should not happen.

Possible solutions: For 1.: Increase gpu memory (obvious). For 2.: Add checks for the texture resolution and error out appropriately. A possible solution would be to circumvent the texture unit for such fat textures (see https://github.com/anholt/mesa/issues/53 for early work), of course this would be slow(er).

[atuyosi]

@jonasarrow Thanks for your reply.

Currently, my GPU memory setting is below ( from /boot/config.txt ):

gpu_mem=128

I set up the GL Driver by raspi-config. and the parameter cma is not set explicitly. What is the relationship between the two parameters cma andgpu_mem?

Here is the result of dmesg | grep cma.

$ dmesg | grep cma
[    0.000000] cma: Reserved 256 MiB at 0x10000000
[    0.000000] Kernel command line: 8250.nr_uarts=0 cma=256M@256M dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1920 bcm2708_fb.fbheight=1080 bcm2709.boardrev=0xa02082 bcm2709.serial=0xd583fc91 smsc95xx.macaddr=B8:27:EB:83:FC:91 bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000  dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[    0.000000] Memory: 619652K/901120K available (6357K kernel code, 432K rwdata, 1716K rodata, 476K init, 764K bss, 19324K reserved, 262144K cma-reserved)
[    1.224115] vc-cma: Videocore CMA driver
[    1.224146] vc-cma: vc_cma_base      = 0x00000000
[    1.224182] vc-cma: vc_cma_size      = 0x00000000 (0 MiB)
[    1.224212] vc-cma: vc_cma_initial   = 0x00000000 (0 MiB)

/boot/cmdline.txt:

$ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

[jonasarrow]

The gpu_mem setting is for the closed source driver, so it is wasted with the open source driver. It can be set to 16if you don't do video decoding and 64if you do.

The cma setting sets a limit, how much memory the open source driver can use. So it can be fairly large, as the memory not used by the driver is available for other programs. Limiting factor is the memory layout. If you go too low or high, some fixed memory regions go into the way. I currently have cma=640M@64M, which is enough for most purposes.

[anholt]

256M is the max the GPU can use. If you go over that, the binner will end up with addressing errors occasionally due to a HW bug. I still need to put a patch in to make sure that user adjustment doesn't violate that requirement.

[atuyosi]

Thanks for a lot.

I confirmed that there is no problem if the image is reduced to 2048x2048 pixels. I'd decide to shrink the image to avoid the problem.

Changing the cma (contiguous memory allocator?) parameter value did not improve it.

[anholt]

You're dropping the size down below the maximum renderable by the 3D engine, and thus avoiding the tiled rendering code in X. My guess would be that glamor's tiled-pixmap Render code is breaking on scaling (that code is clearly garbage, but we had no evidence that it was actually broken until now).

[anholt]

I just tried with glamor on the intel driver with the same texture size limits as vc4 and it rendered fine with a 2448x2448 image. So it doesn't seem to be the X Server, and it's probably just the OOM errors you had. I haven't reproduced the OOMs myself, but commit ebf33e577aee00cf888c79e11a3b62c181b46510 in Mesa may help with them.