Hi @kevin.tx
not yet, unfortunately 
It’s one of my high-priority tasks after coming back in the office.
1 Like
Hi @vix ,
All right. No worries, let us know if you did and we will support you on that. 
Best Regards
Kevin
Hello @kevin.tx, @jeremias.tx, @henrique.tx
finally I had time to test.
I can confirm that under TorizonCore 6.0 the performance of this simple 3D example seems good.
This is an improvement.
And so I went on with another step 
I tried a more complex 3D example (this one).
And unfortunately, with this example the Chromium container crashes.
Here you can see the container log:
chromium_crash.log (3.2 KB)
And here you can see the output from chrome://gpu
It seems that all the hardware acceleration options (WebGL/WebGL2/OpenGL) are enabled and hardware accelerated.
Then we tried with the hardware acceleration flag --disable-gpu-compositing (as described here). The container doesn’t ccrash, but I can see the following error on the screen:
Application error: a client-side exception has occurred (see the browser console for more information)
Here is the log:
chromium_disable_gpu_compositing.log (1.7 KB)
Since the log contains an entry related to ES3 is blocklisted/disabled/unsupported, we try to rebuild the Chromium docker container starting from github forcing the Chromium flag --ignore-gpu-blacklist to check if ES3/WebGL2 was explicitly disabled/blacklisted.
Nothing changed, so it seems it’s not blacklisted, but unsupported.
We also tried using Cog container, but the performance with this simple 3D example are really porr. And so Cog is not an option.
Can you investigate and check why the complex 3D example cannot run?
Thanks
1 Like
I did some testing here and I think I know what’s wrong, so that log message you highlighted: ES3 is blocklisted/disabled/unsupported
So for context this is referring to “OpenGL ES 3.X” specifically. However, as you can see from NXP’s table here: i.MX 8 Series Applications Processors | Arm® Cortex®-A72/A53/A35/M4 cores | NXP Semiconductors
The i.MX8M Mini SoC only supports up to OpenGL ES 2.0. As a test I took our Apalis i.MX8 module which does support OpenGL ES 3.1 and ran the example there (same container as is used on the Verdin i.MX8M Mini). The result is that the example ran, performance was a bit rough but it was working unlike on the Verdin i.MX8M Mini where it just fails.
This leads me to believe that this particular example requires OpenGL ES 3.X and can’t fallback on using OpenGL ES 2.0. If that is the case then there’s not much we can do here since it seems to be a hard limitation of the SoC itself.
Best Regards,
Jeremias
I confirm from NXP side that GPU of iMX8M-Mini supports up to OpenGL ES 2.0. It’s a hardware limit, not a driver/software one.
NXP suggests me to use iMX8M-Nano instead of the Mini, but there is no Verdin with iMX8M-Nano (I think its development has been dropped some years ago) and so I stay with the Mini with this limit.