GeneralAntilles | # 151 | 2008-10-30, 17:26 | Report

My point being, that there's question that the drivers for OMAP3 wont be compatible with OMAP2.

The relationship between getting drivers for OMAP2 and Fremantle, is that if Nokia is able to release Fremantle for OMAP2 hardware, it will either A. Require some extensive modification or B. Require 3D acceleration.

lcuk | # 152 | 2008-10-30, 17:26 | Report

It would be nice to try and get a reasonable software OGL running on this device.

liqbase xv framework can handle the lower level grunt work and resolution independence quite well to reduce the work load.

shame I have no time to consider anything like this.

qgil | # 153 | 2008-10-30, 20:21 | Report

Hi, Kate is the contact at Nokia following this - you know how to find her. For what I know, the situation is still http://wiki.maemo.org/Talk:Drivers_j...iolation_issue , the ball is currently not in Nokia's terrain and the Fremantle release has little to do with all this topic. :/

lcuk | # 154 | 2008-10-30, 20:38 | Report

heh qgil,
this subject just won't go away will it!

regarding my software OGL thinking, I know somewhere there is a software driver stack (or there was).

If anyone can dig out an implementation we could get a wiki page together and get some things through and actually SEE the performance and try to work out how it can be improved.

Afterall, ANY generic OGL is better than none and we would know the playing field.

fanoush | # 155 | 2008-10-30, 20:47 | Report

You mean even possibility of Fremantle release for N8x0 has little to do with it? From the outside it looks like current uncertainty of Fremantle for N8x0 can be related to availability of 3d acceleration for N8x0 devices.

jzencovich | # 156 | 2008-10-30, 21:10 | Report

I'm just curious, how much would it cost to "purchase" a copy of the driver (source or otherwise)?

I heard something about a license cost per device sold.

It's probably very expensive, but it's worth a shot, if anyone can get a ballpark....

I'll look into other omap2 devices.

lardman | # 157 | 2008-10-30, 21:25 | Report

Hmm, so it's down to Ti and/or ImgTech to split the driver into a GPL wrapper + non-GPL binary part I assume?

lcuk | # 158 | 2008-10-30, 21:27 | Report

jzencovich,
The problem with this device is where the powervr writes to.

Unlike other omap2 devices (mainly phones) its not a straight forward binary thats required.
other omap2 devices use the framebuffer directly on the omap2 chip and output video to the lcd directly out of the omap2 itself.

( triangles+textures->powervr->framebuffer->screen )

The nokia device uses a resolution which is simply too large to enable to the use of this on omap framebuffer which meant an alternative seperate LCD driver chip is used which has a framebuffer inside main memory.

(this kind of arrangement is also inside the 770 - the only difference is the older CPU on the 770 did not have a dedicated framebuffer on the cpu chip)

A "normal" driver for other operating systems running the same omap chip therefore will not work and would need to be specially constructed (which is possibly what has happened and appears to exist within nokia).


On the drivers justification page, a possible way through this problem is outlined which would require setting up a pipeline to render 3d data to the internal SRAM framebuffer with the powervr, then using the IVA to convert this data to YUV and sending over to main memory for actual rendering by the LCD chip.
Its a longshot and we have no documentation for any of the components but according to everything I know could get us 640*480 at 30fps...

*de-emphasised due to being told its not sustainable.

Of course, there may be a simpler way to tell the powervr to render its frames directly to main memory (so the lcd can see them) in YUV mode, but again without documentation we will never know.


that is my understanding of the problem, if I'm wrong please correct me.

---

Last edited by lcuk; 2008-10-30 at 21:38.

lardman | # 159 | 2008-10-30, 21:38 | Report

I personally don't think it matters where the framebuffer resides, as long as it's writeable from the kernel (which it is of course). All you'd do is alter the position to which you write.

As lcuk says, there is a bandwidth problem, so rendering full screen is limited (YUV is quicker than RGB, etc.), but that's simply a platform limitation, it shouldn't stop the hardware acceleration from doing its thing, accelerating 2- and 3D transforms and the like.

tom61 | # 160 | 2008-10-31, 00:54 | Report

The Intel/Marvell 2700 has a MBX lite 3D accel., and has (or had) extensive looking documentation on how to use the chip. Could this be of help?

The Dell Axim x50v and x51v had this chip with an OpenGL ES driver for Windows Mobile. There is a port of Quake III: Arena that was playable at 640x480 on the x50v/x51v. I'm guessing it'd be a good target for reverse engineering drivers, if MBX and MBX lite are fully compatible. There are even dual frame buffers if you want to play around with redirecting the 3D output (one framebuffer on the processor SoC, one on the 2700G). Unfortunately, the Linux port for the X50v is not very far along last I checked.