Some precaching textures issues on mesa 19

[ghost]

Hi Anholt, I wanna mention that you work its fantastic. My cornern if there is any hard limitation in preaching aside than how much ram you dedicate to gpu or if there is any driver dev solution to this topic? The games just hangs if i a want to load textures packs for them or just increase the quality of the textures, and the vc can handle them if i switch the quality and resume the game... But no if I start the game with that setup. Thats weird... No matter what amount of mb dedicated to gpu of course. For me its just a hardware limitation... But maybe you could give me another answer. The problem its not onky mesa 19 related of course.

Maybe its just related to my software. Btw, your improvement's have made the games much more stable on manage particles

[anholt]

vc4's memory use is limited by the amount of CMA you have reserved in the system (cma= boot time parameter, or specified in v3d's overlay in the downstream kerenl). You'll get GL_OUT_OF_MEMORY errors once allocations fail in CMA, which can include during draw commands (which also need to allocate memory).

If you were talking about the gpu_mem= config.txt argument, that has no impact on vc4 other than taking memory away from Linux.

[ghost]

Ok. There is any gxx flag to improve a bit this or its a nogo?

[ghost]

Could i compile another kernel to tweak it a bit?

[anholt]

I did mention the cma= kernel parameter, which is what controls how much memory is available to vc4. If you're on downstream raspbian, the v3d overlay may or may not override that parameter, I'm not sure. If you're on that and the kernel parameter doesn't work, then you'd need to adjust the dt overlay.

[ghost]

Ok. So. I know how to modify the kernel because menuconfig its very intuitive but how to modify the v3d overlay? I need to compile mesa with wich parameter?

[ghost]

This could boost a lot my games... So I really appreciate your help.

[anholt]

Setting kernel command line parameters doesn't involve recompiles, go look at how to set them in config.txt. Editing the dt would involve editing the dt and recompiling, but again that's not the starting point. I never mentioned compiling mesa because it's not relevant. Regardless, my bug tracker for mesa bugs is not the place for support on this.

[ghost]

Thanks i will try your solutions. May the force be with me. Thanks. On many ways. Please dont shotdown the topic because it could take time

[ghost]

I am really sorry to bother you with these thing. i will not bother you further, I swear. but here I am right now. I set this parameters: on config.txt: gpu_mem=128 cma_lwm=16 cma_hwm=32 cma_offline_start=16 on cmdline.txt: coherent_pool=6M smsc95xx.turbo_mode=N

nothings change, so, i need to try compile dt overlay with wich parameter?

[anholt]

None of that content you pasted includes the cma= kernel command line parameter, so I wouldn't expect it to have any effect.

[ghost]

Ok, could you send me a test command line? The its no much info about that. Just a test line. If it fails to boot doesnt matter. For example. If I need 256 mb reserved for the gpu...?

[jonasarrow]

Edit cmdline.txt to include (all on a single line, so add it with a whitespace at the end)

 cma=256M@256M

You can play around with the values, first one ist the size, the second is the start address, but 256M should give you some headroom (standard is 64M, I think). There is a limit in the hardware for 256M in the binner, but I think the driver works around this (@anholt is this correct?), so it should be save to even allocate more.

As the Linux driver does not use the gpu_mem memory from config.txt, set is as low as possible (16 for no video decode and 64 for video decode support).

The cma_*lines in config.txt are used by the closed source driver, which you don't use, so they don't do what you want to achieve (and may even rob you some of the memory).

[ghost]

Thanks jonas!! I will try it!!!

[ghost]

Ok. That doesnt fix the issue. Maybe its another thing. Million thanks anyway. Just to close this thread. If the overlay its the problem. What repo I need to compile and with what parameters?. I will no bother you anymore anholt. Sorry for the inconvenient topic.

It should be another problem because mesa driver has a great amount of precaching right now, i set 64 mem to gpu like you suggest and even on that with the cmd line youtube can run at 1080p on chromium... sorta. i never see that kind of performance in video playback on mesa.. I always use normal driver to video playback because its superior obviously

[ghost]

bte, just to avoid some S3TC related problem i compiled mesa with these flag on the makefile "def=" "-DUSE_EXTERNAL_DXTN_LIB=1" but it didnt compile the lib. should i put that somewhere else? like on "defines" instead ? mmm.. i read some more info and its only for x86. could that lib be compiled in mesa on the "hard" way anyway ?

[anholt]

vc4, being a gles2-only part, doesn't do S3TC.

[ghost]

So, it is at hard level. You cant install the lib or if you does it itwill never uncompress s3tc? I installed the lib.so anyway... No change on another game that its proven s3tc conflicting. why the lib its not working?

[ghost]

Iam so sorry for the last desperate message. I found than openmw could unpack the textures before loading the game so now it runs perfect! . going back on topic. After unpacking the vc4-kms-v3d.dtbo overlay and some testing with the problematic game. I found a interesting conclution: cma its at 256 by default. if I set "dtoverlay=vc4-kms-v3d,cma-128" in config.txt the game loading hangs much quicker than without the cma-128 parameter (or any of the others). So, could I go a little more than that ? This its you last dts overlay. I will need to change some values to do that, preferably adding two more cma options to play with them, being 512 the last one. that could be possible? In the game (my problem with precaching its on a lot of games than pushes the pi on his limits in terms of memory) it shoews some arb error but the crash never happens, it just ends with precaching and I have to go to terminal and reboot.

session.log

vc4-kms-v3d-overlay.txt

[ghost]

Isolved with cma=384M on cmdline. the game dosnt show the background and its not playable at this point because of the arb conflict. but thats another story. Doom3/dhewm3 uses OpenGL 1.x with OpenGL ARB shaders. they arent supported on mesa? maybe my mesa 19 installation its wrong in some way.

https://drive.google.com/file/d/1J_cM8gcO7WJwBuiYaEri2aMzvmoTSLb6/view?usp=sharing

GL_PROGRAM_ERROR_STRING_ARB: line 47, char 42: error: invalid vertex attribute reference