<erle>
and i must admit, “Max core profile version: 0.0” seems kinda sus hehe
<austriancoder>
erle: if you are faking a higher opengl version then supported it is just luck that it works
<erle>
austriancoder luck as in “etnaviv is implementing most of the newer opengl stuff, but not all”?
<erle>
funnily enough i get much more fps with nexuiz than with minetest/luanti if i claim to have opengl 3.2, but minetest/luanti is famously wasteful with rendering
<austriancoder>
erle: that and that the application did not use api calls that result in troubles
<austriancoder>
erle: higher opengl/opengles version provide more efficient ways to render
<erle>
austriancoder my experience so far is “apps that have multiple render paths can render more fancy stuff using higher opengl versions, but are usually faster on any hardware i own with the oldest renderer”
<erle>
my suspicion is that in many cases the more efficient ways a) aren't used b) are not more efficient unless your hardware is so new it does not matter
<erle>
like, not everyone orders 100k asteroids and wants only 2 drawcalls to render them if you get what i mean
<erle>
austriancoder do you know of a tool that traces the *actual* opengl requirements of something? or should i just use apitrace and process the output?
<austriancoder>
erle: there are reason why we do not expose higher opengl versions - some required features like 128 bit formats are not supported by the gpus and need to be emulated. a fancy feature from a higher opengl version works per se, but the spec requires support for 128 bit formats. that's why you might see a perf boost.
<austriancoder>
erle: tracing requirements is hard.. as the application can query the list of supported extensions and do what ever it wants with it.
<erle>
austriancoder so i guess it is a bit like that thing where older intel integrated GPUs claim to not be able to do newer openGL because then chrome takes a slower rendering path.
<erle>
austriancoder btw, does the vivante GPU share memory with the host system? i was wondering about the hangs i get in OOM conditions
<austriancoder>
erle: yes it shares memory
<erle>
austriancoder do you know of any way i could reserve RAM as VRAM, e.g. via /proc incantations or device tree magic?
<austriancoder>
there is no way - the etnaviv stack could support memory shrinker if there is an oom situation.
<erle>
austriancoder well evidently my system locks up when i click “Apply immediately” in the effects tab of nexuiz (nexuiz has a memory leak there, every click allocates dozens to hundreds of MB)
<erle>
i mean when i click it often enough
<erle>
i think turning an OOM into a graphics hang that way (music continues to play) is kinda not cool :/
<austriancoder>
feel free to debug it
<erle>
i wish i knew how
<erle>
you know any way to reset the card in such a situation into some safe mode?
<erle>
or any way to start debugging the thing at all?
<erle>
i only have (very little) experience with old ATI and intel integrated graphics
<erle>
with intel it turned out that when you do too many drawcalls they corrupt the screen. with ATI it turned out that the driver must match the BIOS to avoid slowdowns/hangs/corruption.
<austriancoder>
hmm.. you can enable some debug output via ETNA_MESA_DEBUG=resource_msgs and/or you can use valgrind/heaptrack
<erle>
austriancoder do you also have an imx8mq reform 2 with vivante GPU?
<austriancoder>
erle: yes
<erle>
also thank you, i will try to figure out what i can. not much hope, but sometimes i find things others overlook.
<austriancoder>
in about a week I have more time for such debug requests - sorry