Re: Fremantle OpenGL wrapper?
Hi, On Wed, 2009-06-03 at 20:22 +0200, ext Qole wrote: Kimmo and Quim: First of all: I did not start this thread as an attack on the Maemo team, nor was my comment, that's disappointing, meant as an attack. It is a simple statement of fact; it is disappointing to me that Maemo 5 does not yet have the infrastructure in place to be able to run hardware-accelerated 3D graphics in OpenGL ES applications. Running HW-accelerated games (using OpenGL ES2.0) is possible even today by stopping the hildon-desktop (compositor) first. I have a version of hildon-desktop + libmatchbox2 + libclutter that allows switching off the compositor when your window is shown with a special window property. This works, but when showing, e.g. the power key menu (or system-modal dialog on top of your game), it takes about two seconds to switch back to the compositing mode. I don't see how this two-second delay could be reduced, and it could be that the delay will stay about the same due to required reconfiguration in the X server and 3D drivers. However, this is already faster (and more convenient) than stopping and restarting hildon-desktop, and it is also possible to task away from your game to another application and switch back to it later. To me, this is a very important feature for any future device, and I was disappointed that this is not apparently a high priority within Maemo. Probably because the device is not designed as a gaming device, Nokia has other devices that focus on gaming. I really want the next Maemo device to succeed, and one of the first things the gadget blogs and technophiles will want to see is the games. This means making Maemo 5 games friendly, and to me that means making it easy to port existing OpenGL games to Maemo 5. I don't know the internal workings of Maemo, and perhaps you have a good strategy in place for games; I was thinking purely of porting existing Linux games that were written for OpenGL. So I began thinking of what needed to be in place for this porting to be done. I think the community developers can port 3D games for it, and they may even run fast enough, but it's no PSP. I also admit I might have been influenced by the video of Quake3 on the Pandora. :-) I also don't expect Maemo to port the games, I'm just concerned that the path will be too thorny to encourage others to do it. When there's a will, there's a way :P -Kimmo Alan 2009/6/3 Kimmo Hämäläinen kimmo.hamalai...@nokia.com I already said that I'm working on non-composited mode, didn't I? I don't have to do this, but I'm kind person :) snip Well, the device is not out yet, so how far it could be? Thank you for working on it. On Wed, Jun 3, 2009 at 2:11 AM, Quim Gil quim@nokia.com wrote: Hi Qole, Hamalainen Kimmo (Nokia-D/Helsinki) wrote: On Wed, 2009-06-03 at 09:17 +0200, ext Qole wrote: That's quite disappointing. Well, more disappointing would be a hildon-desktop inconsistent, sluggish, buggy and with weird wrong interactions between GTK +, Hildon, Clutter, OpenGL ES, Xorg, OMAP3 kernel... and more brave technologies Kimmo and others are dealing with, putting them for the first time in a commercial product. What Kimmo is saying quite frankly (as he is a pure developer as opposed to people like me, more into words) is First Things First. He is also saying that there is plenty of work only the people in the Fremantle project can do, while there are many other things others can do thanks to all these technologies being open source. It makes sense that Nokia engineers like Kimmo concentrate first on the things that need to be in place in order to release a successful product with Maemo 5 inside. -- Quim Gil open source advocate Maemo Software @ Nokia -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
Qole, see what you are doin'. :) ext Qole wrote: Kimmo and Quim: First of all: I did not start this thread as an attack on the Maemo team, nor was my comment, that's disappointing, meant as an attack. It is a simple statement of fact; it is disappointing to me that Maemo 5 does not yet have the infrastructure in place to be able to run hardware-accelerated 3D graphics in OpenGL ES applications. To me, this is a very important feature for any future device, and I was disappointed that this is not apparently a high priority within Maemo. This is a developers list and you were disappointed by the answer of a developer telling you that the technologies involved are all open source so anybody can contribute to the solution. Kimmo and Kate are giving technical details telling that the enablers are in place and they need fine tuning. They also tell you that such wrapper can be developed by anybody (with the knowledge and the time, sure). No matter how high the priority of your request would be, having the official release and developer offering tops (logically) the priority. Besides, based on this thread you are making your own conclusions in talk.maemo.org about the status of the release etc. I really want the next Maemo device to succeed, and one of the first things the gadget blogs and technophiles will want to see is the games. This means making Maemo 5 games friendly, and to me that means making it easy to port existing OpenGL games to Maemo 5. We also want the next Maemo device to succeed and we have a list of priorities to make this happen. Any input is welcome and your point is taken. Now, please let's move on. Qole, basically you came to a developers list with a user request (OpenGL based games are important and Maemo 5 should be ready for them), you got valuable feedback from Nokia developers but you are still pushing your agenda without getting in development/technical details and you are extending your disappointment here to threads of (mainly user) speculation in tmo. My recommendation is to follow this discussion in talk.maemo.org or maemo-users if you prefer. I don't know the internal workings of Maemo, and perhaps you have a good strategy in place for games; I was thinking purely of porting existing Linux games that were written for OpenGL. So I began thinking of what needed to be in place for this porting to be done. Developers can do this. I also admit I might have been influenced by the video of Quake3 on the Pandora. :-) Pandora is a gaming device, so they better have the gaming enablers in place. I also don't expect Maemo to port the games, I'm just concerned that the path will be too thorny to encourage others to do it. Right. Why don't you ask this in the OpenGL community? It's not Maemo who defines the gaps and incompatibilities between OpenGL flavors and versions. THAT would definitely help the success of the next Maemo device much more than putting more pressure in our developers. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
Hi, Am Mittwoch 03 Juni 2009 schrieb Simon Pickering: Bluetooth games controller/kb! :) There's no officially supported bt game controller. The kernel doesn't even include support for joysticks at all and the keyboard is tiny. This device just hasn't been designed for gaming. And why should it? That's what the pandora is for. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
Quim: Look, I'm very very sorry that the Nokia developers feel that I am putting pressure on them to do something here! I posted first to talk.maemo.org, and then I posted here on the developers list. I hoped to start a discussion about making an OpenGL - GL ES 2 translation library for porting games to Maemo 5, in the manner that is being done in the Pandora community. I really don't know how this discussion has gone off the rails so badly. And why is someone who is more into words contributing to the derailment, while the pure developer has responded to my last post very helpfully? On Thu, Jun 4, 2009 at 1:24 AM, Quim Gil quim@nokia.com wrote: This is a developers list and you were disappointed by the answer of a developer telling you that the technologies involved are all open source so anybody can contribute to the solution. That's not what I said! This is a text medium, all of the text is archived, why are you misquoting me by paraphrasing so badly? Kimmo and Kate are giving technical details telling that the enablers are in place and they need fine tuning. They also tell you that such wrapper can be developed by anybody (with the knowledge and the time, sure). Yes. And I am very grateful that Kimmo is working on it. And I'm very interested by the other solution Kimmo suggested, involving switching off just the compositor. So I'm not disappointed any more. My disappointment stemmed from the fact that I wanted to talk about porting OpenGL games, and I discovered that there's problems that I had no idea about, on a much lower level, blocking the way. Kate and Kimmo detailed problems with my request. Kimmo didn't make it clear at first that these problems were being worked on, and that was disappointing to me. When Kimmo said that hildon-desktop was open source, so we could fix it, I thought that meant it wasn't being worked on, and that it was going to be left entirely to the community to provide some solution. I was wrong, it is being worked on within Maemo, so I'm happy. I don't want to upset the Maemo folks, that is biting the hand that feeds me. But I am an expert at getting everyone upset... :-( Quim wrote: Besides, based on this thread you are making your own conclusions in talk.maemo.org about the status of the release etc. Actually, no, I'm making my guesses based on several threads in this mailing list. They are by no means conclusions. I don't think I've made any conclusions about anything. Just some idle speculations. Any input is welcome and your point is taken. Now, please let's move on. Agreed. I'll move on right now, and I will not address any more points in your post. -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Fremantle OpenGL wrapper?
From: maemo-developers-boun...@maemo.org [maemo-developers-boun...@maemo.org] On Behalf Of ext Qole [qole.tab...@gmail.com] Sent: Thursday, June 04, 2009 9:47 PM To: maemo-dev Subject: Re: Fremantle OpenGL wrapper? I hoped to start a discussion about making an OpenGL - GL ES 2 translation library for porting games to Maemo 5, in the manner that is being done in the Pandora community. I have been having several presentations to maemo community how to use OpenGL-ES in maemo You can find them from my blog http://blogs.forum.nokia.com/blog/kate-alholas-forum-nokia-blog It is ot so much question of transition libraries but understanding what is OpenGL-ES and how it relates to desktop OpenGL I checked openpandora wiki http://pandorawiki.org/Development_tutorials . It looks a like they are having very similar approach, no silver bullet OpenGL to OpenGL-ES translation library but just OpenGL-ES1.1 tutorial and example how to use OpenGL-ES with SDL. I have had my tutorials about how to use OpenGL-ES2.0 and how to use it with Qt . If you read http://pandorawiki.org/OpenGL_ES_1.1_Tutorial . It tells a lot what is the qestion. There is just no single OpenGL but desktop OpenGL has many, many legacy layers of API's . Mobile OpenGL implements only the most efficient subset of them. Because there is hundreds of ways to use OpenGL, there is no simple way to convert. The Openpandora OpenGL-ES1.1 wiki tries to explain ( as i had in my presentations/blog and maemo wiki page ) that as example OpenGL has legacy API glBegin/glVertex/gEnd that are obsoleted in OpenGL-ES and OpenGL-ES only supports way to pass vertexes as array. Of course passing them as array is much more efficient, just one API call with big number of vertexes as opposed one call for one coordinate point. That just an example what is the difference. For game developer it is much more sense port the application to use vertex arrays because it is more efficient also in desktop. When we go to OpenGL-ES2.0 or Desktop OpenGL-2.0, we have thing called programmable shaders. OpenGL1.x or OpenGL-ES1.x has fixed function non programmable pipeline doing transformations and lighting. In OpenGL-(ES)2.0 it is all programmable and it offers much more features to make much better looking games. I strongly recommend to take it in use. If you still would like use fixed function pipeline to port old not so advanced games, you can still use OpenGL-ES1.x emulation libraries in maemo. I hope that we can get them in to next SDK release. Kate ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
Thank you very much! On Thu, Jun 4, 2009 at 2:25 PM, kate.alh...@nokia.com wrote: From: maemo-developers-boun...@maemo.org [ maemo-developers-boun...@maemo.org] On Behalf Of ext Qole [ qole.tab...@gmail.com] Sent: Thursday, June 04, 2009 9:47 PM To: maemo-dev Subject: Re: Fremantle OpenGL wrapper? I hoped to start a discussion about making an OpenGL - GL ES 2 translation library for porting games to Maemo 5, in the manner that is being done in the Pandora community. I have been having several presentations to maemo community how to use OpenGL-ES in maemo You can find them from my blog http://blogs.forum.nokia.com/blog/kate-alholas-forum-nokia-blog It is ot so much question of transition libraries but understanding what is OpenGL-ES and how it relates to desktop OpenGL I checked openpandora wiki http://pandorawiki.org/Development_tutorials . It looks a like they are having very similar approach, no silver bullet OpenGL to OpenGL-ES translation library but just OpenGL-ES1.1 tutorial and example how to use OpenGL-ES with SDL. I have had my tutorials about how to use OpenGL-ES2.0 and how to use it with Qt . If you read http://pandorawiki.org/OpenGL_ES_1.1_Tutorial . It tells a lot what is the qestion. There is just no single OpenGL but desktop OpenGL has many, many legacy layers of API's . Mobile OpenGL implements only the most efficient subset of them. Because there is hundreds of ways to use OpenGL, there is no simple way to convert. The Openpandora OpenGL-ES1.1 wiki tries to explain ( as i had in my presentations/blog and maemo wiki page ) that as example OpenGL has legacy API glBegin/glVertex/gEnd that are obsoleted in OpenGL-ES and OpenGL-ES only supports way to pass vertexes as array. Of course passing them as array is much more efficient, just one API call with big number of vertexes as opposed one call for one coordinate point. That just an example what is the difference. For game developer it is much more sense port the application to use vertex arrays because it is more efficient also in desktop. When we go to OpenGL-ES2.0 or Desktop OpenGL-2.0, we have thing called programmable shaders. OpenGL1.x or OpenGL-ES1.x has fixed function non programmable pipeline doing transformations and lighting. In OpenGL-(ES)2.0 it is all programmable and it offers much more features to make much better looking games. I strongly recommend to take it in use. If you still would like use fixed function pipeline to port old not so advanced games, you can still use OpenGL-ES1.x emulation libraries in maemo. I hope that we can get them in to next SDK release. Kate ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
OpenGL is not available in the device but OpenGL ES2 is. Notice that this is a big problem when porting OpenGL applications from the desktop PC world. Some kind of OpenGL to OpenGLES conversion layers are possible but with some FPS cost, I assume. Something like this perhaps, I imagine there are also others: http://forum.openhandhelds.org/viewtopic.php?f=14t=884 Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
On Wed, 2009-06-03 at 09:17 +0200, ext Qole wrote: That's quite disappointing. Don't worry, hildon-desktop will be open-source, so you can fix it yourself ;) -Kimmo I'm looking forward to seeing further news about game mode, I guess. 2009/6/2 Kimmo Hämäläinen kimmo.hamalai...@nokia.com Hi, On Wed, 2009-06-03 at 00:53 +0200, ext Qole wrote: On Tue, Jun 2, 2009 at 3:04 PM, David Greaves da...@dgreaves.com wrote: I understood that GL wasn't going to be available to the apps on the device... something about the window manager permanently taking the only viewport? I am not sure if this is a beta-phase bug or a hardware or GLES issue. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... I think you are referring to the following two posts, both by Kimmo Hämäläinen. I don't believe they say that GL won't be available, but that there will be a performance hit OpenGL is not available in the device but OpenGL ES2 is. Notice that this is a big problem when porting OpenGL applications from the desktop PC world. Some kind of OpenGL to OpenGLES conversion layers are possible but with some FPS cost, I assume. because the apps will have to go through Hildon-Desktop to render, rather than rendering directly. Yes, about 30% penalty with the compositor, but I'm working on non- composited or game mode for hildon-desktop that allows shutting down the compositor and rendering directly to the screen (without killing hildon-desktop). I still need to get it working with dialogs and menus popping on top of the non-composited application, but I guess it'll work in the end somehow. BR; Kimmo http://lists.maemo.org/pipermail/maemo-developers/2009- March/018639.html As Kate has already proven, multi-context works. But as long as you have hildon-desktop running in the background, you will not render directly to the screen even if you use Clutter/QtGraphicsView/EGL+OpenGLES2.0/whatnot in your application. When hildon-desktop is running, it is the only one drawing on the screen (with the exception of XVideo). So, killing hildon- desktop is the only way to get direct rendering to the screen at the moment. (We might have something more elegant for this in the future...) http://lists.maemo.org/pipermail/maemo-developers/2009- March/018645.html Keeping the compositor around has some performance impact, because after the application draws to an offscreen pixmap (the window), the X server sends Damage events (saying this part of the pixmap changed) to hildon-desktop, and hildon-desktop asks the 3D HW to use this pixmap in a OpenGL texture and draw it to the screen. So, there is some extra delay (maybe 10-25ms) after the application's drawing is visible. Second implication is that you cannot use HW accelerated zooming and moving of textures for the whole graphical pipeline. You can use it for drawing into your window, but when hildon-desktop draws to the screen, it cannot use it (e.g. it cannot say move this content to there). It will just get a big damage area that is updated by updating the OpenGL texture content. Third implication: to save memory, we are using the texture- from-pixmap GL extension to allow the X server and 3D HW share the pixmap data. This means that while 3D HW is accessing the pixmap data (while
Re: Fremantle OpenGL wrapper?
ext Qole wrote: On Tue, Jun 2, 2009 at 1:14 PM, kate.alh...@nokia.com mailto:kate.alh...@nokia.com wrote: From: maemo-developers-boun...@maemo.org mailto:maemo-developers-boun...@maemo.org [maemo-developers-boun...@maemo.org mailto:maemo-developers-boun...@maemo.org] On Behalf Of ext Qole [qole.tab...@gmail.com mailto:qole.tab...@gmail.com] Sent: Tuesday, June 02, 2009 9:05 PM To: maemo-developers Subject: Fremantle OpenGL wrapper? Hi all, I'm not much of a developer, but I really think it would be a good idea to get a couple OpenGL wrappers ready for Fremantle. What do you like the wrapper do ? If you like to get easiest way to run OpenGL you can take example skeleton from Imagination OpenGL-ES2.0 examples. They run in Fremantle, you just need to compile them or then you can take Qt GLWidget as it is done in hellogl_es2 that is part of Qt4.5 source. I also runs nicely in Fremantle. Good thing using Qt as a wrapper is that you can use full GL but you can mix it with Qt UI widgets or QGraphicsWiew higer level drawing primitives. Kate I am asking for a wrapper that will make it possible to port existing OpenGL applications (mainly games) to Maemo 5+ without having to do any real rewriting. I gave an example in my e-mail of an SDL game that uses OpenGL. If your solutions will allow someone to port a game like Armagetron Advanced without much effort, then that is what I'm looking for. If this means rewriting the game / application, then that's not what I'm asking for. A good way to know if your solution is what I'm looking for is to take the Debian Lenny source code of Armagetron Advanced (http://packages.debian.org/source/lenny/armagetronad) and make a Qt / Imagination wrapper for it, then compile it to run on Fremantle. If this takes a very long time, then this isn't what I'm looking for. I'm looking for something that would be a drop-in replacement for the OpenGL libraries for games like Quake2 or SDL games like Armagetron. I hane not used SDL myself, so i hope that someone more familiar to it can comment how much work is needed to make to use OpenGL-ES2 in maemo. I checked little bit Armagedonad source code and it least looks that there is used OpenGL 1.x style primitives in eDisplay.cpp . OpenGL-ES2.0 != OpenGL 1.x . You can check http://wiki.maemo.org/OpenGL-ES . To port applications that use OpenGL-1.x API to OpenGL-ES2.0 need to use new API that you need to use if you are porting for desktop OpenGL 3.0 . You may think, these aren't important, they're only games, but I would disagree. And I'm not even a gamer. I don't think so, i think that games are very important applications. They have a lot of users, there is lot of business with them . I was just saying that there is already many ways to take OpenGL-ES in use in maemo. Kate -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
That's quite disappointing. I'm looking forward to seeing further news about game mode, I guess. 2009/6/2 Kimmo Hämäläinen kimmo.hamalai...@nokia.com Hi, On Wed, 2009-06-03 at 00:53 +0200, ext Qole wrote: On Tue, Jun 2, 2009 at 3:04 PM, David Greaves da...@dgreaves.com wrote: I understood that GL wasn't going to be available to the apps on the device... something about the window manager permanently taking the only viewport? I am not sure if this is a beta-phase bug or a hardware or GLES issue. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... I think you are referring to the following two posts, both by Kimmo Hämäläinen. I don't believe they say that GL won't be available, but that there will be a performance hit OpenGL is not available in the device but OpenGL ES2 is. Notice that this is a big problem when porting OpenGL applications from the desktop PC world. Some kind of OpenGL to OpenGLES conversion layers are possible but with some FPS cost, I assume. because the apps will have to go through Hildon-Desktop to render, rather than rendering directly. Yes, about 30% penalty with the compositor, but I'm working on non- composited or game mode for hildon-desktop that allows shutting down the compositor and rendering directly to the screen (without killing hildon-desktop). I still need to get it working with dialogs and menus popping on top of the non-composited application, but I guess it'll work in the end somehow. BR; Kimmo http://lists.maemo.org/pipermail/maemo-developers/2009- March/018639.html As Kate has already proven, multi-context works. But as long as you have hildon-desktop running in the background, you will not render directly to the screen even if you use Clutter/QtGraphicsView/EGL+OpenGLES2.0/whatnot in your application. When hildon-desktop is running, it is the only one drawing on the screen (with the exception of XVideo). So, killing hildon-desktop is the only way to get direct rendering to the screen at the moment. (We might have something more elegant for this in the future...) http://lists.maemo.org/pipermail/maemo-developers/2009- March/018645.html Keeping the compositor around has some performance impact, because after the application draws to an offscreen pixmap (the window), the X server sends Damage events (saying this part of the pixmap changed) to hildon-desktop, and hildon-desktop asks the 3D HW to use this pixmap in a OpenGL texture and draw it to the screen. So, there is some extra delay (maybe 10-25ms) after the application's drawing is visible. Second implication is that you cannot use HW accelerated zooming and moving of textures for the whole graphical pipeline. You can use it for drawing into your window, but when hildon-desktop draws to the screen, it cannot use it (e.g. it cannot say move this content to there). It will just get a big damage area that is updated by updating the OpenGL texture content. Third implication: to save memory, we are using the texture- from-pixmap GL extension to allow the X server and 3D HW share the pixmap data. This means that while 3D HW is accessing the pixmap data (while transferring it to the 3D chip), X server cannot access it. Thus, while the compositor is updating the screen, it is slowing down X drawing. However, it's not mandatory to use texture-from-pixmap, but then you are paying the price in increased RAM usage. -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
Kate Alhola wrote: I hane not used SDL myself, so i hope that someone more familiar to it can comment how much work is needed to make to use OpenGL-ES2 in maemo. I checked little bit Armagedonad source code and it least looks that there is used OpenGL 1.x style primitives in eDisplay.cpp . OpenGL-ES2.0 != OpenGL 1.x . You can check http://wiki.maemo.org/OpenGL-ES . To port applications that use OpenGL-1.x API to OpenGL-ES2.0 need to use new API that you need to use if you are porting for desktop OpenGL 3.0 . I think qole is asking for a wrapper library, that offers a OpenGL-1.x / OpenGL-2.0 API and translates those calls on the fly to OpenGL-ES2.0. With a library like that it would be possible to run standard/non-mobile OpenGL applications on Maemo without changing much of the code. Sorry, if this is already clear, I had the feeling that there is some misunderstanding... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
On Wed, Jun 3, 2009 at 9:25 AM, Kate Alhola kate.alh...@nokia.com wrote: OpenGL-ES2.0 != OpenGL 1.x . You can check http://wiki.maemo.org/OpenGL-ES . To port applications that use OpenGL-1.x API to OpenGL-ES2.0 need to use new API that you need to use if you are porting for desktop OpenGL 3.0 . My understanding is that OpenGL 3.0 still has all of the features of OpenGL 2.x. On the other hand OpenGL 3.1 removed the features that were deprecated in 3.0 (such as begin/end). Laurent ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
On Wed, Jun 3, 2009 at 1:06 AM, Cornelius Hald h...@icandy.de wrote: I think qole is asking for a wrapper library, that offers a OpenGL-1.x / OpenGL-2.0 API and translates those calls on the fly to OpenGL-ES2.0. With a library like that it would be possible to run standard/non-mobile OpenGL applications on Maemo without changing much of the code. Sorry, if this is already clear, I had the feeling that there is some misunderstanding... I'm glad somebody understands what I'm asking. I only wish the good folks at Nokia understood. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Fremantle OpenGL wrapper?
Kate Alhola wrote: i think that games are very important applications. They have a lot of users, there is lot of business with them . Indeed. If you look at the top applications in the Apple app store then you will see they are pretty much exclusively games. There is a lot of demand for games on mobile devices. Kate Regards, Jamie -- http://www.linuxuk.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
On Wed, 2009-06-03 at 10:07 +0200, ext Qole wrote: 2009/6/3 Kimmo Hämäläinen kimmo.hamalai...@nokia.com On Wed, 2009-06-03 at 09:17 +0200, ext Qole wrote: That's quite disappointing. Don't worry, hildon-desktop will be open-source, so you can fix it yourself ;) No, I said in my first e-mail that I'm not a developer. And I'm not paid by Nokia. And if you wait for the community to fix it, you'll have waited too long. I'm an engaged user and a great Maemo fan who just sees a problem -- very few options to develop for the hardware-accelerated graphics for Maemo 5 -- and I think it needs to be addressed now, before hardware is released. I find your fix it yourself attitude strange. Do you not see a problem here? Which problem? Is a 30% performance penalty for 3D applications acceptable? I already said that I'm working on non-composited mode, didn't I? I don't have to do this, but I'm kind person :) Do you want people to write hardware-accelerated applications for Maemo? Sure. Nobody is preventing that. There will be a great many more people expressing disappointment if this issue isn't addressed in a timely fashion. I'm sure you are working on it; I have faith you'll fix the problem; I only wish this area was farther along in development. Well, the device is not out yet, so how far it could be? -Kimmo -Kimmo I'm looking forward to seeing further news about game mode, I guess. 2009/6/2 Kimmo Hämäläinen kimmo.hamalai...@nokia.com Hi, On Wed, 2009-06-03 at 00:53 +0200, ext Qole wrote: On Tue, Jun 2, 2009 at 3:04 PM, David Greaves da...@dgreaves.com wrote: I understood that GL wasn't going to be available to the apps on the device... something about the window manager permanently taking the only viewport? I am not sure if this is a beta-phase bug or a hardware or GLES issue. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... I think you are referring to the following two posts, both by Kimmo Hämäläinen. I don't believe they say that GL won't be available, but that there will be a performance hit OpenGL is not available in the device but OpenGL ES2 is. Notice that this is a big problem when porting OpenGL applications from the desktop PC world. Some kind of OpenGL to OpenGLES conversion layers are possible but with some FPS cost, I assume. because the apps will have to go through Hildon- Desktop to render, rather than rendering directly. Yes, about 30% penalty with the compositor, but I'm working on non- composited or game mode for hildon-desktop that allows shutting down the compositor and rendering directly to the screen (without killing hildon-desktop). I still need to get it working with dialogs and menus popping on top of the non-composited application, but I guess it'll work in the end somehow. BR; Kimmo http://lists.maemo.org/pipermail/maemo- developers/2009- March/018639.html As Kate has already proven, multi-context works. But as long as you have hildon-desktop running in the background, you will not render directly to the screen even if you use Clutter/QtGraphicsView/EGL +OpenGLES2.0/whatnot in your application. When hildon-desktop is running, it is the only
RE: Fremantle OpenGL wrapper?
Dear Kate, Could you post a note where the relevant repositories for fermantle and open GL are ? Mikk0 Terh0 -Original Message- From: Alhola Kate (Nokia-FNDC/Helsinki) Sent: 02.06.2009, 23:22 To: qole.tab...@gmail.com; maemo-developers@maemo.org Subject: RE: Fremantle OpenGL wrapper? From: maemo-developers-boun...@maemo.org [maemo-developers-boun...@maemo.org] On Behalf Of ext Qole [qole.tab...@gmail.com] Sent: Tuesday, June 02, 2009 9:05 PM To: maemo-developers Subject: Fremantle OpenGL wrapper? Hi all, I'm not much of a developer, but I really think it would be a good idea to get a couple OpenGL wrappers ready for Fremantle. What do you like the wrapper do ? If you like to get easiest way to run OpenGL you can take example skeleton from Imagination OpenGL-ES2.0 examples. They run in Fremantle, you just need to compile them or then you can take Qt GLWidget as it is done in hellogl_es2 that is part of Qt4.5 source. I also runs nicely in Fremantle. Good thing using Qt as a wrapper is that you can use full GL but you can mix it with Qt UI widgets or QGraphicsWiew higer level drawing primitives. Kate I have a thread on talk.maemo.orghttp://talk.maemo.org[1], but maybe I should be posting here too. [1] http://talk.maemo.org/showthread.php?t=29085 I think there should be a wrapper for applications that use OpenGL directly, and maybe an SDL library for games that use OpenGL via SDL. There's work in this area for the Pandora, but I haven't seen much yet for Maemo devices. I propose starting with a simple test game like Armagetron Advanced [2], which actually runs on an N800 at 3 fps with software OpenGL rendering. This game uses SDL and the mesa GL libraries, which suggests that an SDL library like the one developed for the Pandora [3] might work here. [2] http://packages.debian.org/lenny/armagetronad [3] http://www.gp32x.com/board/index.php?showtopic=48023 Like I said, I'm not really a developer, and I can't really take these ideas and make them happen. But I'm paying close enough attention to these things to see that this seems to be an important gap in the available software right now. I would prefer comments on my talk.maemo.orghttp://talk.maemo.org thread, but you can discuss here, too. -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
Hi Qole, Hamalainen Kimmo (Nokia-D/Helsinki) wrote: On Wed, 2009-06-03 at 09:17 +0200, ext Qole wrote: That's quite disappointing. Well, more disappointing would be a hildon-desktop inconsistent, sluggish, buggy and with weird wrong interactions between GTK+, Hildon, Clutter, OpenGL ES, Xorg, OMAP3 kernel... and more brave technologies Kimmo and others are dealing with, putting them for the first time in a commercial product. What Kimmo is saying quite frankly (as he is a pure developer as opposed to people like me, more into words) is First Things First. He is also saying that there is plenty of work only the people in the Fremantle project can do, while there are many other things others can do thanks to all these technologies being open source. It makes sense that Nokia engineers like Kimmo concentrate first on the things that need to be in place in order to release a successful product with Maemo 5 inside. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
Terho Mikko.J (Nokia-D/Tampere) wrote: Dear Kate, Could you post a note where the relevant repositories for fermantle and open GL are ? OpenGL-ES development libraries are part of Fremantle SDK Imagination SDK can be loaded from http://www.imgtec.com/powervr/insider/sdk/KhronosOpenGLES2xSGX.asp The Imagination SDK contains lots of example applicatins etc. Qt OpenGL is included in Qt Fremantle port that is in extras-devel repository deb http://repository.maemo.org/extras-devel fremantle free non-free Kate Mikk0 Terh0 -Original Message- From: Alhola Kate (Nokia-FNDC/Helsinki) Sent: 02.06.2009, 23:22 To: qole.tab...@gmail.com; maemo-developers@maemo.org Subject: RE: Fremantle OpenGL wrapper? From: maemo-developers-boun...@maemo.org [maemo-developers-boun...@maemo.org] On Behalf Of ext Qole [qole.tab...@gmail.com] Sent: Tuesday, June 02, 2009 9:05 PM To: maemo-developers Subject: Fremantle OpenGL wrapper? Hi all, I'm not much of a developer, but I really think it would be a good idea to get a couple OpenGL wrappers ready for Fremantle. What do you like the wrapper do ? If you like to get easiest way to run OpenGL you can take example skeleton from Imagination OpenGL-ES2.0 examples. They run in Fremantle, you just need to compile them or then you can take Qt GLWidget as it is done in hellogl_es2 that is part of Qt4.5 source. I also runs nicely in Fremantle. Good thing using Qt as a wrapper is that you can use full GL but you can mix it with Qt UI widgets or QGraphicsWiew higer level drawing primitives. Kate I have a thread on talk.maemo.orghttp://talk.maemo.org[1], but maybe I should be posting here too. [1] http://talk.maemo.org/showthread.php?t=29085 I think there should be a wrapper for applications that use OpenGL directly, and maybe an SDL library for games that use OpenGL via SDL. There's work in this area for the Pandora, but I haven't seen much yet for Maemo devices. I propose starting with a simple test game like Armagetron Advanced [2], which actually runs on an N800 at 3 fps with software OpenGL rendering. This game uses SDL and the mesa GL libraries, which suggests that an SDL library like the one developed for the Pandora [3] might work here. [2] http://packages.debian.org/lenny/armagetronad [3] http://www.gp32x.com/board/index.php?showtopic=48023 Like I said, I'm not really a developer, and I can't really take these ideas and make them happen. But I'm paying close enough attention to these things to see that this seems to be an important gap in the available software right now. I would prefer comments on my talk.maemo.orghttp://talk.maemo.org thread, but you can discuss here, too. -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
ext Cornelius Hald wrote: Kate Alhola wrote: I hane not used SDL myself, so i hope that someone more familiar to it can comment how much work is needed to make to use OpenGL-ES2 in maemo. I checked little bit Armagedonad source code and it least looks that there is used OpenGL 1.x style primitives in eDisplay.cpp . OpenGL-ES2.0 != OpenGL 1.x . You can check http://wiki.maemo.org/OpenGL-ES . To port applications that use OpenGL-1.x API to OpenGL-ES2.0 need to use new API that you need to use if you are porting for desktop OpenGL 3.0 . I think qole is asking for a wrapper library, that offers a OpenGL-1.x / OpenGL-2.0 API and translates those calls on the fly to OpenGL-ES2.0. With a library like that it would be possible to run standard/non-mobile OpenGL applications on Maemo without changing much of the code. I don't know is the translation library from desktop OpenGL to OpenGL-ES sense at all. OpenGL-ES is made as mobile optimized and translation may be heavy. OpenGL-ES1.0 is much more similar than Desktop OpenGL1.0 where you can use fixed function pipeline API. In OpenGL-ES2.0 you need to use programable shaders. If you have application that is made using OpenGL1.x style API it won't be so big work to translate code to OpenGL-ES1.x . There is Imagination OpenGL-ES1.x emulation libraries for Omap3/ SGX gpu (opengles-sgx-img-common, libgles1-sgx-img) . I noticed that they are not (yet ?) part of published beta SDK. In practice what they do is that they load shaders that emulates OpenGL-ES1.x fixed function pipeline and then API wrappers for OpenGL-ES1.x API. I tested and it looks a like they work nicely with our device. I need to propose that they would be also included to out next SDK Kate Sorry, if this is already clear, I had the feeling that there is some misunderstanding... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
Hi, Am Mittwoch 03 Juni 2009 schrieb Qole: I really want the next Maemo device to succeed, and one of the first things the gadget blogs and technophiles will want to see is the games. This means Playing games? What input method do you expect to use? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
Am Mittwoch 03 Juni 2009 schrieb Qole: I really want the next Maemo device to succeed, and one of the first things the gadget blogs and technophiles will want to see is the games. This means Playing games? What input method do you expect to use? Till Bluetooth games controller/kb! :) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
If you accept that games are the most popular category for the iphone, and you also accept that it doesn't have a keyboard, then worrying about the input method on the maemo platform seems a bit too far down in the details as long as the maemo platform has at least the same input methods as the iphone. Anything else is a bonus. Frank On Wed, Jun 3, 2009 at 2:31 PM, Qole qole.tab...@gmail.com wrote: On Wed, Jun 3, 2009 at 12:22 PM, Simon Pickering s.g.picker...@bath.ac.uk wrote: Am Mittwoch 03 Juni 2009 schrieb Qole: I really want the next Maemo device to succeed, and one of the first things the gadget blogs and technophiles will want to see is the games. This means Playing games? What input method do you expect to use? Till Bluetooth games controller/kb! :) I was thinking the keyboard, but the accelerometer could be used, too... -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
On Wed, Jun 3, 2009 at 8:31 PM, Qole qole.tab...@gmail.com wrote: On Wed, Jun 3, 2009 at 12:22 PM, Simon Pickering s.g.picker...@bath.ac.uk wrote: Am Mittwoch 03 Juni 2009 schrieb Qole: I really want the next Maemo device to succeed, and one of the first things the gadget blogs and technophiles will want to see is the games. This means Playing games? What input method do you expect to use? Till Bluetooth games controller/kb! :) I was thinking the keyboard, but the accelerometer could be used, too... As a example: http://www.youtube.com/watch?v=260Kpiqv9_U (playing Duke Nukem 3d with accelerometers) Best regards, -- Valério Valério http://www.valeriovalerio.org -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Fremantle OpenGL wrapper?
From: maemo-developers-boun...@maemo.org [maemo-developers-boun...@maemo.org] On Behalf Of ext Qole [qole.tab...@gmail.com] Sent: Tuesday, June 02, 2009 9:05 PM To: maemo-developers Subject: Fremantle OpenGL wrapper? Hi all, I'm not much of a developer, but I really think it would be a good idea to get a couple OpenGL wrappers ready for Fremantle. What do you like the wrapper do ? If you like to get easiest way to run OpenGL you can take example skeleton from Imagination OpenGL-ES2.0 examples. They run in Fremantle, you just need to compile them or then you can take Qt GLWidget as it is done in hellogl_es2 that is part of Qt4.5 source. I also runs nicely in Fremantle. Good thing using Qt as a wrapper is that you can use full GL but you can mix it with Qt UI widgets or QGraphicsWiew higer level drawing primitives. Kate I have a thread on talk.maemo.orghttp://talk.maemo.org[1], but maybe I should be posting here too. [1] http://talk.maemo.org/showthread.php?t=29085 I think there should be a wrapper for applications that use OpenGL directly, and maybe an SDL library for games that use OpenGL via SDL. There's work in this area for the Pandora, but I haven't seen much yet for Maemo devices. I propose starting with a simple test game like Armagetron Advanced [2], which actually runs on an N800 at 3 fps with software OpenGL rendering. This game uses SDL and the mesa GL libraries, which suggests that an SDL library like the one developed for the Pandora [3] might work here. [2] http://packages.debian.org/lenny/armagetronad [3] http://www.gp32x.com/board/index.php?showtopic=48023 Like I said, I'm not really a developer, and I can't really take these ideas and make them happen. But I'm paying close enough attention to these things to see that this seems to be an important gap in the available software right now. I would prefer comments on my talk.maemo.orghttp://talk.maemo.org thread, but you can discuss here, too. -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
On Tue, Jun 2, 2009 at 3:04 PM, David Greaves da...@dgreaves.com wrote: I understood that GL wasn't going to be available to the apps on the device... something about the window manager permanently taking the only viewport? I am not sure if this is a beta-phase bug or a hardware or GLES issue. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... I think you are referring to the following two posts, both by Kimmo Hämäläinen. I don't believe they say that GL won't be available, but that there will be a performance hit because the apps will have to go through Hildon-Desktop to render, rather than rendering directly. http://lists.maemo.org/pipermail/maemo-developers/2009-March/018639.html As Kate has already proven, multi-context works. But as long as you have hildon-desktop running in the background, you will not render directly to the screen even if you use Clutter/QtGraphicsView/EGL+OpenGLES2.0/whatnot in your application. When hildon-desktop is running, it is the only one drawing on the screen (with the exception of XVideo). So, killing hildon-desktop is the only way to get direct rendering to the screen at the moment. (We might have something more elegant for this in the future...) http://lists.maemo.org/pipermail/maemo-developers/2009-March/018645.html Keeping the compositor around has some performance impact, because after the application draws to an offscreen pixmap (the window), the X server sends Damage events (saying this part of the pixmap changed) to hildon-desktop, and hildon-desktop asks the 3D HW to use this pixmap in a OpenGL texture and draw it to the screen. So, there is some extra delay (maybe 10-25ms) after the application's drawing is visible. Second implication is that you cannot use HW accelerated zooming and moving of textures for the whole graphical pipeline. You can use it for drawing into your window, but when hildon-desktop draws to the screen, it cannot use it (e.g. it cannot say move this content to there). It will just get a big damage area that is updated by updating the OpenGL texture content. Third implication: to save memory, we are using the texture-from-pixmap GL extension to allow the X server and 3D HW share the pixmap data. This means that while 3D HW is accessing the pixmap data (while transferring it to the 3D chip), X server cannot access it. Thus, while the compositor is updating the screen, it is slowing down X drawing. However, it's not mandatory to use texture-from-pixmap, but then you are paying the price in increased RAM usage. -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
Hi, On Wed, 2009-06-03 at 00:53 +0200, ext Qole wrote: On Tue, Jun 2, 2009 at 3:04 PM, David Greaves da...@dgreaves.com wrote: I understood that GL wasn't going to be available to the apps on the device... something about the window manager permanently taking the only viewport? I am not sure if this is a beta-phase bug or a hardware or GLES issue. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... I think you are referring to the following two posts, both by Kimmo Hämäläinen. I don't believe they say that GL won't be available, but that there will be a performance hit OpenGL is not available in the device but OpenGL ES2 is. Notice that this is a big problem when porting OpenGL applications from the desktop PC world. Some kind of OpenGL to OpenGLES conversion layers are possible but with some FPS cost, I assume. because the apps will have to go through Hildon-Desktop to render, rather than rendering directly. Yes, about 30% penalty with the compositor, but I'm working on non- composited or game mode for hildon-desktop that allows shutting down the compositor and rendering directly to the screen (without killing hildon-desktop). I still need to get it working with dialogs and menus popping on top of the non-composited application, but I guess it'll work in the end somehow. BR; Kimmo http://lists.maemo.org/pipermail/maemo-developers/2009- March/018639.html As Kate has already proven, multi-context works. But as long as you have hildon-desktop running in the background, you will not render directly to the screen even if you use Clutter/QtGraphicsView/EGL+OpenGLES2.0/whatnot in your application. When hildon-desktop is running, it is the only one drawing on the screen (with the exception of XVideo). So, killing hildon-desktop is the only way to get direct rendering to the screen at the moment. (We might have something more elegant for this in the future...) http://lists.maemo.org/pipermail/maemo-developers/2009- March/018645.html Keeping the compositor around has some performance impact, because after the application draws to an offscreen pixmap (the window), the X server sends Damage events (saying this part of the pixmap changed) to hildon-desktop, and hildon-desktop asks the 3D HW to use this pixmap in a OpenGL texture and draw it to the screen. So, there is some extra delay (maybe 10-25ms) after the application's drawing is visible. Second implication is that you cannot use HW accelerated zooming and moving of textures for the whole graphical pipeline. You can use it for drawing into your window, but when hildon-desktop draws to the screen, it cannot use it (e.g. it cannot say move this content to there). It will just get a big damage area that is updated by updating the OpenGL texture content. Third implication: to save memory, we are using the texture- from-pixmap GL extension to allow the X server and 3D HW share the pixmap data. This means that while 3D HW is accessing the pixmap data (while transferring it to the 3D chip), X server cannot access it. Thus, while the compositor is updating the screen, it is slowing down X drawing. However, it's not mandatory to use texture-from-pixmap, but then you are paying the price in increased RAM usage. -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
