[[ TileCache ]] Use HardwareBuffer for direct memory access on Android #7433
Conversation
There was a problem hiding this comment.
Overall I suggest making a simple API which returns false if hardwarebuffer stuff fails for the ciritcal places - perhaps MCTileCacheHardwareBuffer prefix. (Seems we only need Create / Unlock / Update / Destroy).
I suggest using forward references near the top, then implementing them at the bottom in an ifdef. If there is no hardwarebuffer implementation then the methods should just return false meaning the non-hardwarebuffer code is used.
This means that the only places we need to use the ifdefs are in the super_tile struct and around the methods - with dummy impls of the latter in the alternate.
Also, we need to make sure we dlsym the AHardwareBuffer symbols so things run on pre-8.0.
engine/src/glcontext.cpp
Outdated
| @@ -20,6 +20,12 @@ along with LiveCode. If not see <http://www.gnu.org/licenses/>. */ | ||
| #import <OpenGLES/ES3/gl.h> | ||
| #import <OpenGLES/ES3/glext.h> | ||
| #elif defined(TARGET_SUBPLATFORM_ANDROID) | ||
|
|
||
| /* TODO - Don't attempt to build on 32bit armv7 - needs ndk update */ | ||
| #if !defined(__arm__) |
There was a problem hiding this comment.
So I need an idea on what (at least!) is involved in doing this to work out if it is worth the effort.
67245e1 to
bb39db2
Compare
|
@runrevmark I've revised this PR so that platform-specific code is moved to a seperate source file, and implemented the fallback for Android < 26. I've also abstracted the hardwarebuffer stuff generally and moved the #ifdef`d stuff to the bottom of the tilecache source as advised |
bb39db2 to
4e37411
Compare
This patch adds an "external texture" program type to the glcontext implementation which is similar to the regular texture program except that an EGL extension is used to access an external texture.
This patch adds an API for obtaining a hardware buffer that can be bound to a GL texture and locked for direct access to the memory buffer. This is implemented on Android using the AHardwareBuffer C api. The API functions are dynamically loaded to avoid linkage failures when attempting to run on Android versions that don't support the APIs.
This patch modifies the creation and update of GL textures to use a native hardware buffer. This allows fast upload of texture data by accessing the underlying buffer and copying pixel data to the texture directly.
This patch allows armv7 builds to complete successfully until the NDK can be updated to one that includes the required headers (android/hardware_buffer.h).
4e37411 to
5baadb1
Compare
This patch modifies the creation and update of GL textures to use a
native hardware buffer. This allows fast upload of texture data by
accessing the underlying buffer and copying pixel data to the texture
directly.
To do:
Of these the first is critical (otherwise the engine will not work on anything less than Android 8.0). The second would be nice, but isn't hugely important - 64-bit devices are common-place, even more so as API level increases.