On Sat, 28 Jun 2008 13:26:24 +0300 Mikko Rauhala <[EMAIL PROTECTED]> babbled:
> la, 2008-06-28 kello 09:43 +0200, Michael Stather kirjoitti: > > At least this is what I read, > > since neither read 2D or 3D acceleration is possible. > > That is quite an overstatement of the problems. At least Xv and mpeg4 > accelerations are possible with available software. I don't know exactly > how much accelerated support there otherwise is, but at least seems from > public statements that basic stuff like blitting/solid fills/rotation > etc is there. So please, while the Glamo is no panacea, and the > bandwidth issues are real enough, no FUD that nothing is possible with > it. bingo. correct. the mpeg4 accel is definitely hackish as there is no well defined access api/system for it. it wont forward-=port to any new/different soc's. > Also, while this is purely speculative, balrog-kun (the guy responsible > for mpeg-4 acceleration) at least at some point had some ambitions on > doing basic 3d acceleration support, but that would probably require > running in QVGA mode even if that pans out. (The Glamo is not really > designed for VGA displays even if it can drive one.) yup. 3d accel wont be doable in vga. the max 3d buffer size is 511x511 (less than vga in 1 dimension), so going down to qvga will be needed. you cover the issues quite well here. i'm just confirming it. :) > > So I wonder why this was done that way (since the older model had a much > > larger bandwidth), and whether it's changed for the next release. > > It is public information that the Glamo is off the table for GTA03 due > to it not panning out quite as well as was originally hoped. > > As for why, I can only speculate. The short specs without the caveats > were attractive enough, they got permission to do a free driver, and the > Glamo provided an extra SD controller (though limited by its bus) which > was necessary with the wifi chip requiring one. yup. when you read initial specs for glamo you go "oooh nice". then you find the gotchas. (256x256 max texture size, no render-to-texture, 511x511 max 3d destination buffer size, ...) and you being to see how much work it will be to work with it. if we had a qvga display glamo would be a better match. vga is at the upper limit of the glamo. a lot of stuff CAN be done. given enough time and effort and willingness to accept the limitations (eg yes - 3d can be done, but only openglES 1.1, and qvga output). i had been thinking of doing all 2d accel via the 3d pipe at one point. this would have given us fantastic support for xrender, compositing, 3d for games and more, but the limitations made me realise we'd fall short on many parts of that pipeline. it's all possible - but there are things that will limit you, and that's just a fact of life with the chip. i didn't have any idea access to/from video ram would be the speed it is. we did try dma to alleviate it - but that was a failed experiment. in the end we have product to ship and what is there now is "good enough". we can't go delaying a product forever to play games for 1 graphics chip. > > I mean e.g. games (3D games, or emulators) are IMHO an important part of > > the functionality of such a smartphone. > > For fast-paced games you might want to use QVGA mode to alleviate the > bandwidth issues, but IMAO on such a small screen that isn't a bad deal > anyway (for fast-paced games spesifically). Something like scumm > adventure games should be fine in higher resolution, but that isn't a > promise as I don't have a GTA02 myself yet (the order _is_ in :). yup. qvga would help a lot. > Realize that the GTA03 will apparently be dumb framebuffer again, like > GTA01. While that speeds up pure blitting to the screen from the main > memory, do not expect wonders from it either. > > Where future devices go, we shall see. The reality is that most high-end > embedded graphics stuff is closed as hell. What with Android and even > Nokia announcing preliminary plans for Linux phones, there are quite > enough high-profile companies doing this stuff with no regard for real > openness (witness Android FAQ and partner list, and Nokia's Maemo). yup. the way graphics on embedded is going is that it is part of the cpu (soc). so you get what you get with the soc. you don't choose it separately. this itself makes lots of dev work to squeeze everything from the glamo a less attractive proposition. we need to tread carefully in the future to ensure: 1. our products stay OPEN. 2. we try and provide as much as possible given limitations. the glamo is not bad - if you don't try and push it. we, unfortunately, are pushing it already by virtue of shipping a vga lcd. :) then it begins to show that it has limitations. > I for one would like OpenMoko to differentiate in this respect and stay > the course even with the difficulties it may pose. > > -- > Mikko Rauhala - [EMAIL PROTECTED] - <URL:http://www.iki.fi/mjr/> > Transhumanist - WTA member - <URL:http://www.transhumanism.org/> > Singularitarian - SIAI supporter - <URL:http://www.singinst.org/> > > > > > _______________________________________________ > Openmoko community mailing list > [email protected] > http://lists.openmoko.org/mailman/listinfo/community -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
