As with all devices, the capability of the hw does not imply that the software provided will allow that capability. Without the appropriate support ( drivers and libraries ) from the HW manufacturer there is nothing much you can do. You mentioned that the shim module does not have the functions required for ES3…what functions specifically are you referring to…as OpenGL ES 3.1 will have additional entry point that OpenGL ES 3.0 will not have, so by ES3 are you referring to OpenGL ES 3.0 ?
Sorry I should have been clearer, it is specifically es3.1 I am requiring, for the Jetson tk1 device. I am using the sdk supplied here “https://developer.nvidia.com/platform-software-development”, which states support for OpenGL ES 3.1.
I have used the gl31.h header from another device (a jeston pro using vibrante), but the program fails to link with undefined references to “glMemoryBarrier”, “glTexLevelParameteriv” and “glBindImageTexture”, which in the “es” apis became available in es3.1.
I am fairly sure the device is capable of these features, however they are lacking from the libGLES2v2 lib.
Hi thanks for your help, I’m still having troubles though!
So the es3 examples in the gamesamples do use the functions I am looking for, also link against GLESv2 in the android makefiles. I’m running ubuntu, I can’t test the examples, though I assume the GLESv2 lib is the same?
produces no results, I’ve tried the same with all libGLESv2 libs I can find on the system (and in the JetPack download).
I have got this working on the Jetson Pro, which does have a GLESv2 lib with the es3 functions in it (I obviously tried to use that too, to no avail). It has the same graphics chip I believe.
I wonder if I can use that vibrante sdk on the non-pro jetson?
Thanks again for your help, think I may have hit a dead end.
I don’t know about the glMemoryBarrier etc. functions you mentioned. I do find them in the GL lib, but I don’t know if it’s possible for the GLES to use parts of GL lib (GLES 3 matches quite well some of the GL versions, afaik). At least I didn’t find a direct link dependency between them.
you should not be calling GL functions without a GL context. If the symbols are missing from the library you are linking against, then there is nothing you can do without getting an updated library with the symbols…GL and GLES are never to be mixed…If you can access the device filesystem…find the shared object on the device and see if the appropriate symbol is present as a test…if it is, then you need to get an updated SDK. Again, the device being capable does not imply that your program will build as these are 2 separate issue. A few have mentioned the headers…but the headers will not help…but you are on the right path with the library…because one MUST link with the stub implementation or some other means of having the GL functions defined or else your application will NOT build…