Does anyone know how to get LWJGL to use OpenGL ES 2 instead of OpenGL 2?
I have an OMAP4 based computer (Panda Board). It has powerful OpenGL ES 2
graphics accleration, but no acceleration for vanilla OpenGL 2.
I think it would also open up a lot of possibilities in the mobile device world to
have an Open GL ES 2 based LWJGL.
I've been meaning to add support for ES 2.0 for a few months now, but didn't have the free time to do it yet. The code is ready (EGL, GL ES 2.0 + extensions), just need to merge it with the current codebase and clean it up a bit. In any case, don't expect a non-x86 build from LWJGL. You'll have to checkout the project and cross-compile it for ARM on your own.
It already is there for ARM. It is at least in the Ubuntu 10.10 sources for ARMEL. The main problem
is that it doesn't find the graphics acceleration.
Apparently you don't have to do much to be able to support ARM.
But there wouldn't be much point in adding Open GL ES 2.0 support without supporting ARM, I think.
I don't know of any X86 systems that use Open GL ES 2.0, but NVidia Tegra, OMAP3, OMAP4,
Snapdragon, etc. all use OpenGL ES. They are all ARM. In some applications they are used
almost like a PC.
Quote from: spasi on April 22, 2011, 15:06:50
I've been meaning to add support for ES 2.0 for a few months now, but didn't have the free time to do it yet. The code is ready (EGL, GL ES 2.0 + extensions), just need to merge it with the current codebase and clean it up a bit. In any case, don't expect a non-x86 build from LWJGL. You'll have to checkout the project and cross-compile it for ARM on your own.
How will we maintain it down the road if we dont have some devices to test it regularly on? and do test builds?
That's my point, we can't have true support for the time being.
I have this implementation lying around, it has been tested extensively for many months and I had it running on a high-end ARM-based device. The code works and it is indeed very easy to cross-compile to ARM, assuming you have a proper toolchain available. Now, that project has been cancelled and I got permission to use the code in LWJGL and that's all I can offer atm. I don't have access to the hardware or toolchain anymore, so in the best case I can do tests on x86 using a desktop ES emulator.
I'm hoping that someone else will jump in and properly maintain this, with access to hardware, etc. I'm not sure how easy it's going to be to produce an ARM build that works on more than one device out there (don't forget about audio/input too). The toolchains are constantly being updated, we're going to have Windows on ARM soon, it's going to be a lot of work (and testing). Anyway, I'm guessing that people that genuinely want to deploy applications using LWJGL ES will want to build on their own (e.g. to add support for custom input controls for their target device).
So, I'll try to incorporate my code in a way that allows someone to easily build this for ARM and also make sure that it doesn't interfere with the rest of LWJGL. Sounds good?
I can test it in Ubuntu 10.10 on the Panda Board. Do you have a test applet that you use for testing?
could you add a patch for this too? http://semiaccurate.com/2011/04/26/arm-jumps-in-to-opencl-with-both-cpu-and-gpus/ :-* ;D
No need for a patch, OpenCL should just worktm anywhere, as long as there's a driver available in the execution environment. :)
I can also test it on Tegra 2 in the near future. I also have a Nokia N900 (OMAP3), but I couldn't find a jre in its repositories, so I have to either compile it or find it.
I can test it immediately. Just post here if you'd like to contact me.
OK, I'll post in this thread when I commit the code. Will take a while as I'm quite busy these days.
Spasi, do you want help merging your implementation?
Nah, I just haven't had the time yet. I've been extremely busy lately; we're about to do a massive update to our online system and we were also affected by the Amazon disaster (http://aws.amazon.com/message/65648/), so I haven't slept properly for about 3 weeks as you can imagine. It should cool down next week, I'll update this thread once I've made some progress.
I've started working on this. The biggest problem atm is that the implementation I have assumed 32bit memory space, so I'll have to port everything to use longs for proper integration with LWJGL. Looks relatively clean so far, EGL, GLES20 and all extensions have been merged without serious issues. I've made a new package for now (org.lwjgl.opengles) but I'm not sure if I'll manage to keep it this way, I may have to put some stuff in .opengl for package-private access.
I'll keep you posted on further progress.
depending on the visibility of you work, you could consider creating a branch in the svn.
Most of the code is in place now. Next step is fixing the native code (mostly removing WGL/GLX stuff), will take a while, our window/context management implementation isn't exactly clean. Good news is that the desktop version is compiling properly now. Hopefully everything will work exactly like they are now in the trunk (both API and build-wise) and we'll have a couple extra targets for ES (e.g. "jars_es" and "compile_native_es") that will generate a separate build for OpenGL ES specifically.
Btw, I've made the branch (/branches/opengles), will start committing in there, probably tomorrow.
OK, LWJGL is in the Ubuntu repository in the armel port, but I will have to build your new ES version. Then I can test it.
Hopefully I can figure out how to build it in Ubuntu 11.04 in a reasonable amount of time. I am just upgrading from 10.10 to 11.04. Then I need to run the tests to see if OpenGL ES2 and so forth works in 11.04, and if not, get the needed packages. I am hoping to get a Trim Slice computer soon, then the Tegra testing can be done.
I've been trying to build it in my x86_64 Fedora box, but my JRE is the wrong version, or I am missing some other detail. It just spews out hundreds of errors when I run ant. I've been busy too, but nothing like the Amazon cloud disaster.
I dont think he has comitted it yet ;D
he just created a branch containing trunk
It will probably take me a few days to get Ubuntu upgraded and graphics accel. working.
Compiling the natives on an arm target will be the challenge. I've been trying to compile the latest stable branch in Fedora.
I haven't had much success, and I couldn't find much documentation on how to compile a Linux target.
There is some of Spasi's code in there already in the /branches directory.
I got the windows build to run on Sunday, the linux one yesterday and I also added support for a bunch of non-NV extensions. I'll do a bit of clean-up and commit this afternoon. That branch doesn't have anything ES related yet.
Everything has been committed now, feel free to checkout the branch and do some tests. Details:
- OpenGL ES 2.0 support only, there's nothing for 1.x.
- No Mac support, AWT integration and Pbuffer not supported.
- All extensions are supported, except old ones that targeted ES 1.x (fixed-function and fixed-point data stuff).
- Simple API; everything like normal LWJGL, except you use a new package (org.lwjgl.opengles). There are new PixelFormat, ContextAttribs, GLContext and ContextCapabilities classes in there. Display is still in org.lwjgl.opengl and there are new methods to create GLES contexts. For example:
Display.createES();
Display.create(new org.lwjgl.opengles.PixelFormat());
There are a few new ANT targets for ES:
- generate-opengles
- generate-opengles-debug
- generate-opengles-capabilities
- compile_native_es
- jars_es
To build on a clean checkout, run the following:
- ant generate-all
- ant compile_native_es
I have included an OpenGL ES emulator in libs. It's PVRVFrame from Imagination Technologies, it's the most functional one in my experience. To run with the ES build on desktop, you need to add the emulator to the execution path.
- On Windows:
SET PATH=%PATH%;.\libs\windows (run this once)
java -cp bin -Djava.library.path=libs/windows org.lwjgl.test.opengles.Gears
- On Linux:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./libs/linux (run this once)
java -cp bin -Djava.library.path=libs/linux org.lwjgl.test.opengles.Gears
As you can see I have ported some of our tests to OpenGL ES. The org.lwjgl.test.opengles.util package contains a bunch of utility classes that will get you quickly started with ES2.0. Since there's no fixed-functionality present, you're going to have to use shaders, VBOs, etc. The GLMatrix class is particularly interesting because it simulates the fixed-function OpenGL matrix stack, you simply import it statically and you can use stuff like glLoadMatrix, glTranslatef, etc, then you do a glGetMatrix to get the current matrix to upload to your shader uniform. See the Gears demo source code for details.
Enjoy and let me know if you encounter any issues.
Btw, if you seriously plan to use this on an ARM device, you will probably have to do a few changes to the current source code. First is removing anything AWT related. Even if the VM you run on supports AWT, you really want to avoid touching AWT, it's too much memory bloat for mobile devices. Second is changing LWJGL to assume 32-bit pointers (also avoid anything long/double related). This requires more changes, but it's doable.
Quote from: spasi on May 17, 2011, 17:47:15
Btw, if you seriously plan to use this on an ARM device, you will probably have to do a few changes to the current source code. First is removing anything AWT related. Even if the VM you run on supports AWT, you really want to avoid touching AWT, it's too much memory bloat for mobile devices. Second is changing LWJGL to assume 32-bit pointers (also avoid anything long/double related). This requires more changes, but it's doable.
OK I will get on that as soon as I can. I can check it on OMAP4 (Panda board) in Ubuntu Maverick and possibly OMAP3 and Freescale i.MX515.
Hey frostybeard, any news?
Has anyone else tried building and testing the ES branch?
I actually having problems to build it but that's more because of my lack of c++ / eclipse wisdom (native libraries). However, OpenGL ES integration is a great thing. I would be happy to see this beeing merged into the trunk some day!