I had a topic question on the old forum which shown an issue with the Mali-T6xx driver being terribly slow with both glBufferSubData and glMapBufferRange with the unsync bit set.
I was wondering if there has been any information on if the situation has improved on your end. I've followed the guide here for installing a Unix system on my Chromebook with the latest drivers you provide to the public and the issue is still there.
Any way to get an update on if its fixed and just pending an update somewhere?
Hi sonicadvance1,
Is there any chance you could post a reproducing test case so we can clearly see what issue you are running in to?
The devil is in the detail for most cases of this type of performance bottlenecks, as they usually stem from OpenGL ES's synchronous view of the world interacting badly with the reality of a pipelined rendering architecture. For example, if you try to modify data which is still referenced by a pending rendering operation in the command stream we either need to clone the resource or flush out the rendering state until the data is no longer referenced. Using GLES 3 with glMapBufferRange with the unsynchronized bit should avoid most of those architectural issues of course, so if you can post a reproducer we will be happy to investigate.
Thanks for reporting, Pete
I provided a test case in the previous forum which is now wiped and I don't feel like rewriting the example right now.
I know in the publicly released drivers that the unsync bit is completely ignored, so I already know the reason why the code fails there.
I just want to know if a newer version of the drivers that does support the unsync bit will be coming that I can install on my Chromebook.
> just want to know if a newer version of the drivers that does support the unsync bit
I can confirm this issue has been fixed in our latest drivers, but we don't know the update schedules for our customers' devices as this is not controlled by ARM.
Regards,
Pete
ARM has publicly released drivers here, http://malideveloper.arm.com/develop-for-mali/features/graphics-and-compute-development-on-samsung-chromebook/
Surely that page is controlled by ARM?
Yes, true - if you have rooted the Chromebook you have more options. The r3 drivers linked off that page don't include the fix - I'll check with our ecosystem team who maintain that distribution what the publishing schedule is for the r4 drivers.
Thanks, Pete
Awesome, thank you.
I know it has only been a week, but I tend to find action gets more results than idling. Any developments on r4p0 getting pushed out to people?
No public date yet, sorry. Our r4 driver release is still under development, so we've not yet got a release schedule we can share. I'll update this when I have something more concrete than that.
Best regards,
R4P0 is now released, so I'll poke the relevant team and ask when Chromebook builds will be released.
Fancy. Hopefully this time for kernel changes we can have a combined diff file instead of a bunch of text to copy and paste
Any update on this?
It would be nice to test the r4p0 drivers before my next application release that is coming soon.
If I could enable my glBufferSubData or glMapBufferRange paths it would be very nice.
Any further news on the r4p0 userspace drivers?
Very soon now, it's in testing