View Single Post
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
Hello. When reading this I feel ashamed that I constantly cannot find any time to work on this and yet I think could do a lot. Too bad the whole Maemo thing didn't start few years earlier. I wish I could give same time to N8x0/N900 that I spent with 770. Now back to the 3d.

There is the page, please update it with your findings if possible. With my last update I see it ends with "TODO - document GPL-ed kernel parts" which means Stskeeps had to figure it out again in the post above :-(

Yes omaplcd is the device dependent part of 3d drivers that needs to be changed.

As for the vsync in N8x0 situation. I think we don't want to hook into vsync interrrupt directly. Current omapfb driver already uses it quite sensibly. You either schedule omapfb update and it is started immediatelly (either for smaller screen parts or if you don't care) or you can set the tearsync flag when doing the update ioctl (fullscreen update in video playback) and the update is fired automatically next time vsync comes. So the omaplcd flip matches to scheduling omapfb update with tearsync flag. But for the start this can be ignored, just scheduling the update would be good start.

Next question is where the 3d frame buffers should be stored and how it relates to already preallocated three omapfb planes. This is related to the current allocation failure. As mentioned in older thread I think it should be doable to steal/render into already allocated planes instead of allocating yet another memory dynamically.

This relates to the
PVRSRV_ERROR GetBackBuffer(OMAPLCD_DEVINFO *psDevInfo, IMG_UINT32 ui32Num) procedure. There is code for static memory (flipbuffers array) and dynamic memory and default is dynamic one.

Current sizes of already allocated memory ( see also this)
omapfb: s1d13745 LCD controller rev 1 initialized (CNF pins 3)
omapfb: region0 phys 80600000 virt ffa01000 size=770048 type=0
omapfb: region1 phys 80700000 virt ffabd000 size=786432 type=0
omapfb: region2 phys 87c00000 virt ffb7d000 size=1572864 type=0
omapfb: Framebuffer initialized. Total vram 3129344 planes 3

I think the last plane is good enough for two 800x480x16bits flipbuffers. Basically I think we should abuse the current way how Xvideo and video output is done but instead of video we should point 3d chip to same memory overwriting the video. This would also allow scaling in the same way it currently works with video etc. Sounds crazy? Maybe it is.

I'l try to get back to documenting what I know about the 3d kernel part in the wiki.

Additionally for anyone working on this it could helpful to be familiar with omapfb driver and how it works with external display controllers. The 770 version is a bit easier to understand. N8x0 version is similar, it just switches sossi for rfbi for transfering the data, hw472.c is replaced with blizzard.c and the biggest difference is adding 3 planes due to OMAP2 chip having native support for 3 planes (named GFX, VID0,VID1?) . It was not clear to me at the time N800 came since there is no OMAP2 documentation but when OMAP3 came recently, it looks to me that the video subsystem of OMAP2 is exactly the same as OMAP3 (planes, tv-out, dispc, rfbi ..) so I finally understand a bit better why there are three planes allocated when in the end all three are merged anyway when transferring display data to the epson chip.

Also maybe it should be useful to study how omaplcd.ko part of SGX driver for OMAP3 works since it could be quite similar.
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.

Last edited by fanoush; 2010-05-12 at 08:27. Reason: typos

The Following 25 Users Say Thank You to fanoush For This Useful Post: