Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

This is a continuation of the very lengthy thread of The N800 has a 3D accelerator, right?

Instead, this focuses on actually getting the drivers and libraries to play nice. As it really should be possible.

I think we should be focusing on Graphics_SDK/OMAP24xx_MBX_SDK_N8xx/MBX_Linux_KM/embedded/3rdparty/omap24xx_lcd , not the MBX part of it (which looks cross-device).

Now, where do we stand. The first clue is that the OMAPLCD can't get an IRQ. Now, what is this IRQ/interrupt used for? Vsync (omaplcd_linux.c, InstallVsyncISR())

What's Vsync? Some of you may know this from discussions about tearing, etc. In this case, the interrupt it is waiting for, is the signal that it has begun to update the display and we can start filling in the framebuffer with the next frame.

Now, this is what the driver does, except that well, the framebuffer it is filling into, is the one that is 'staging area' for the real LCD framebuffer. In N8x0, this is the old OMAP framebuffer. We have to send a signal to update the LCD framebuffer. This is also why the driver doesn't work for N8x0 as intended but shows results if we really force a framebuffer transfer.

In the old setup, a Vsync interrupt would be the indication to the driver to take a frame from the queue of rendered frames, remove it from the queue and point the framebuffer pointer at it, as I understand it. This is the Flip() stuff mentioned in the kernel.

In our N8x0 setup, we would not have a Vsync interrupt. We might be able to get one through Blizzard though.

We'd be replacing the Flip() command with our own - take a rendered frame from the queue, push it to LCD controller. See blizzard.c in kernel for reference.

However, if we don't have a vsync interrupt, we will have to find some way to push as soon as we get a frame. As far as I can see, omaplcd_ddc_process_vsyncflip is the entry point for the new frames, which gets added into the queue.

So, for starters, I would see if we can hack omaplcd_ddc_process_vsyncflip to do our bidding.

It looks like VSyncFlip takes render items, Flip()s them and then runs a 'command complete' signal.

Now, shouldn't it be in reach to make this driver do our bidding?

EDIT: Wouldn't it work 'for starters' to hack the omaplcd_ddc_process_vsyncflip to flip immediately, not put in queue and have a user process regularly sending the 'update window' ioctl?

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

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 http://wiki.maemo.org/MBX_drivers_status 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.

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

There is two parameters to the omaplcd module:

module_param(fbsize, long, 0);
MODULE_PARM_DESC(fbsize, "Sets the size of the buffers in a flip chain (default=153600)");
module_param_array(flipbuffers, long, 0, 0);
MODULE_PARM_DESC(flipbuffers, "Sets the address of the buffers in a flip chain (default=0 -> allocated)");

And a piece of code further down, looks a little broken:

#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0))
for(i=0; i < OMAPLCD_MAX_BACKBUFFERS + 1; i++)
{
if(flipbuffers[i])
num_buffers++;
}
#endif

- num_buffers should probably be set to 2 in this case. We can probably hardwire the locations and num_buffers to the video framebuffer

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

Oh! fanoush just showed up. If he sticks around, this could really start moving forward! If Stskeeps and fanoush start working together on this, we'll have to come up with a superhero team name for them. :)

Framebuffer flippers? 3D Heroes? :D

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

...Avatars?

/me ducks and runs

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

Crysis please.

P.S. I don't understand any word you wrote, but it seems to be something nice :)

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

I hate how the driver works. So omaplcd passes mbxaccess a .so filename which passes it to its clients which dlopen it which use it to access the /dev/omaplcd device node which gets back to omaplcd again which eventually sets omap dss registers on its own or calls mbxaccess. :(

This is clearly designed so that the author of display class device drivers can choose whether to implement most of the logic in user space or kernel space -- If we could follow this we could create a libomaplcd.so replacement which calls into blizzard/xv/omaplcd/whatever user space library you can think of.

But of course, we can't.

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

Ah, I almost forgot that other superhero of the 3D drivers, javispedro!

Framebuffer Flippers GO!

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

My hacking project for tonight, since Finland is on holiday tomorrow - seeing if I can build the driver for our 2.6.33 kernel. Worth knowing how screwed we are on that front.

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

OK, I've set up a gitorious project at http://gitorious.org/mbx-n8x0/mbx-n8...s/trees/master and a team for it (poke me to get added)

I've cleaned up the build system and am now using normal Linux kernel build system.

That means:

make CROSS_COMPILE=/path/to/cross-compiler KERNELDIR=/where/my/kernel-sources/are ARCH=arm

to compile it. Not the insane TI build system.

Oh, and it dual builds on 2.6.33 and 2.6.21. Could someone replicate the steps please for 2.6.21 and try to use the .ko's resulting?

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

This might be useful, as the two chips are very similar.

http://bunnitude.com/misc/files/omap/pdf/sprufa4.pdf

We use RFBI to send to the LCD controller, I believe.

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

So, Flip():

Together with this from the graphics subsystem manual mentioned above:

Base address of the graphics buffer in system memory (DSS.DISPC_GFX_BAi registers): The default
value of these two registers at reset time is 0x0. The horizontal resolution is one pixel because the
base address is aligned on a pixel size boundary. In case of 4 BPP, the resolution is two pixels; for 2
BPP, resolution is four pixels; for 1 BPP, resolution is eight pixels; and for RGB24 packed format, the
resolution is four pixels. The vertical resolution is one line. The register DSS.DISPC_GFX_BA0 defines
the base address of the even field; and DSS.DISPC_GFX_BA1 defines the base of the odd field in the
case of an external synchronization and based on the value of the input signal DISPC_FID and the
polarity. To improve system throughput, the base address should be aligned on the burst size
boundary.

Means Flip() is basically pointing that particular plane to the address and then noting the chip about it (GOLCD). Now, my thought is then to do along these lines, pseudocode galore:

When doing a flip (ie, point to a new framebuffer to be shown), - yes, this call is exported by blizzard.c.

int blizzard_update_window_async(struct fb_info *fbi,
struct omapfb_update_window *win,
void (*complete_callback)(void *arg),
void *complete_callback_data)

with a callback being the Vsync ISR, with the IRQ parts removed. That then checks if there's things to be flipped and runs complete() calls and all that stuff and calls a Flip() if need be, making it possible to get Vsync ISR called again.

If I'm right and omaplcd_ddc_process_vsyncflip is actually the entry point for the incoming frames, the first Flip() it does when there's no frames waiting in queue besides the incoming (read: no need to wait for vsync, just write to the buffer), will make sure the VsyncFlip() method gets called each time it's done transferring/flipping a frame.

Now, how difficult is it for us to add blizzard_update_window_async support in Flip() and strip out the IRQ stuff of the ISR, and provide a callback wrapper for VSyncFlip for blizzard_update_window_async?

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

So, my implementation of AllocContiguousMemory:
It will crash you say?

Madness! The damn driver works as usual. I even get the usual triangles on the screen (after a forced blizzard push). So what's happening here?
Initial reasoning: omaplcd IS NOT allocating the real framebuffer, but just wasting some memory. And quite a bit of precious dma memory, for a start.

For skeptics, the kernel BUGS when trying to kill mbxdaemon because it then tries to free 0x01...

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

:mad::mad::(:(:(:(:(:(:(:(:(:(:(:(:( :confused: :confused: :confused: :confused:

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

hello hardware folks,
i can really be saying something stupied,
- but can´t the MBX stream/flush the data without reserving a DMA buffer?
- are the memmory values " [ 83.820312] AllocContiguousMemory(size=768000)" enough or excceds the actual free memmory?
- could someone write an e-mail to the lcd manufactor for help, just "asking" how is the I/O of the lcd?

Anyway, if i say ******** plaese follow up,
thank you for all efforts you are doing and go ahead! you can make it!

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

:takes a deep breath:

Okay, so, libomaplcd.ko is actually what we see in the kernel driver. With Flip() and so on, down to actually writing into BA0.

A simple look into the debug symbols confirms this suspicion:

static void Flip(OMAPLCD_DEVINFO *, long unsigned int);
static void FlushQueue(OMAPLCD_DEVINFO *, void (*)(IMG_VOID *, long unsigned int), IMG_VOID *);

PVRSRV_ERROR MapFBRegRange(OMAPLCD_CLIENT_DEVINFO *, OMAPLCD_DEVINFO *);
PVRSRV_ERROR MapSwapChain(OMAPLCD_CLIENT_DEVINFO *, OMAPLCD_CLIENT_SWAP_CHAIN *);
IMG_BOOL OMAPLCDBridge(IMG_HANDLE, IMG_UINT32, IMG_VOID *, IMG_UINT32, IMG_VOID *, IMG_UINT32);
IMG_UINT32 ReadReg(IMG_VOID *);

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

I've contacted my TI contact to see if he can add a hook to the libomaplcd.so file. Let's see if they still react..

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

I have heard from my TI contact and he said 'I will look in to it and will do want I can.' (assuming he means 'what' and not 'want'). That looks good :)

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

I've sent the following to my TI contact:

Thanks for offering this.

What we need is:

After every call to the function static void Flip(OMAPLCD_DEVINFO *,
long unsigned int), there should be a ioctl made into kernel, using
OMAPLCDBridge, to the following ioctl:

#define OMAPLCDIO_PERFORMED_FLIP _IOWR('F', 0x41, struct
OMAPLCD_INIT_MAIN_IN_DATA_TAG)

A similar call can probably be seen if you look for
OMAPLCDIO_DEINIT_MAIN in your current code.

We can implement the kernel side ourselves, we just need the user code
to call this each time it has run Flip() :)

The reason for this to be done after each Flip() call, is so we can
start a data transfer of the framebuffer to the external LCD
controller in kernel, of the framebuffer it just flipped to.

Thank you!

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

any news if it worked? hmmm i'm not the kernel geek type of guy....:rolleyes:

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

Is it already time to give up with 3D driver or has this TI guy given any comments if he could do something about it? (Yes, it stupid to ask since you would most likely report here if the guy actually had done something :rolleyes: )

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

OK, so, one of the original ideas by javispedro was to write our own WSEGL. I decided to follow up a bit on that idea.

A 'open enough' specification of wsegl.h can be found from http://qt.gitorious.org/qt/qt-gberg/...owervr/wsegl.h

An example WSEGL can be found from http://qt.gitorious.com/qt/qt/blobs/.../pvrqwswsegl.c

Now, this file mentions an interesting part of being a WSEGL:

/* Swap the contents of a drawable to the screen */
static WSEGLError wseglSwapDrawable(WSEGLDrawableHandle _drawable, unsigned long data)

So, my idea is to do the following: Have a WSEGL that our powervr.ini points to. This WSEGL is actually just dlopen()'ing the X11 WSEGL and wraps around it, replacing/extending some functions.

The idea is then in static WSEGLError wseglSwapDrawable(WSEGLDrawableHandle _drawable, unsigned long data) to send a OMAPFB_UPDATE_WINDOW initially for the full screen when the procedure has been executed. For optimization (send only parts of screen), it should be possible to retrieve information on the drawable's nature in longer term.

An initial skeleton of this 'wrapperwsegl' can be found at http://stskeeps.subnetmask.net/maemo...wrapperwsegl.c

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

I've finished up the 'stub' WSEGL. It now outputs whenever any of the functions are being called.

http://stskeeps.subnetmask.net/maemo...wrapperwsegl.c

I have put up a .so people can try for using as a WSEGL at http://stskeeps.subnetmask.net/maemo...rapperwsegl.so

It's compiled in DIABLO_ARMEL with gcc -shared -o wrapperwsegl.so wrapperwsegl.c -ldl

Drop the .so in /usr/lib

You need to put in /etc/powervr.ini:
[default]
WindowSystem=wrapperwsegl.so

.. and let me know of the results (I'm not at home at the moment, so I can't test myself).

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

is it made for 810 or can i test it on 800 as well? can it harm or brick the system and how i get a good report to send you with if it is ok or not?

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

If you have to ask, I don't think you should test it. lol

Jesse~

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

Well, my WSEGL trick worked, see above URL(s) for .so to try out.. I run a ./xegltest unmodified. There's some HW recovery issues still I need to look into, but I see two spinning triangles but sometimes goes to a slow framerate.

Video to come. This is cool.

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

Keep up the great work Stskeeps. We all look forward to your hard work paying off. :D

Jesse~

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

This is interesting... Had to blow off the dust from my old N810 to try this out. I did all the "installation steps" as requested but don't know how to run the xegltest?

The file /etc/powervr.ini didn't exist. I did create that file. Correct?

How can I tell if the wrapper is running? Should I see something with lsmod?

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

Thanks indeed!
Yes, exactly what I was experiencing with the manual omapfb call after swap buffers (well, more like a complete and periodic halt) ;).

At least looks like we might be able to skip an unneeded framebuffer copy with a custom WSEGL. "XV_WSEGL" anyone? ;)

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

EDIT: This is my 1000th post on TMO. Time to retire? :>

OK, step by step guide for my current setup, from a fresh N810 with openssh installed. You'll need the Graphics SDK stuff obviously.

1. Flash this kernel - config at http://stskeeps.subnetmask.net/maemo.org/gl/.config

2. SCP OMAP24xx_MBX_SDK_N8xx/bin/binary_omap2420_linux_debug to /root/binary_omap2420_linux_debug

3. Copy omaplcd.ko and mbxaccess.ko into the same directory. This is the driver from http://gitorious.org/mbx-n8x0/mbx-n8x0-modules along with nobackbuffers.patch to save some DMA memory.

4. Copy *.so from binary_omap2420_linux_debug to /usr/lib and run ldconfig

5. Copy mbxdaemon from binary_omap2420_linux_debug to /usr/bin

6. Put in /etc/powervr.ini:

[default]
WindowSystem=wrapperwsegl.so

and upload http://stskeeps.subnetmask.net/maemo...rapperwsegl.so to /usr/lib

4. Start up the MBX daemon..
4. Fix up libXau.0 link:

ln -s /usr/lib/libXau.so.6 /usr/lib/libXau.so.0

5. As user, that is, from your X-Terminal, now:

You should now see spinning triangles with some stalls. In the x-terminal you'll observe a bunch of MBX hardware recovery messages..

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

For future reference of things that might come in handy if we want to write our own display class:

Breakpoint 1, GetDisplayJumpTable (psDisplayJumpTable=0x16c1c) at omaplcd_client.c:1792
1792 omaplcd_client.c: No such file or directory.
in omaplcd_client.c
(gdb) print psDisplayJumpTable
$1 = (DISPLAY_CLASS_JUMP_TABLE *) 0x16c1c
(gdb) print *psDisplayJumpTable
$2 = {pfnInitDevice = 0, pfnDeInitDevice = 0, pfnEnumerateFormats = 0, pfnEnumerateDims = 0, pfnSetMode = 0,
pfnCreateSwapChain = 0, pfnDestroySwapChain = 0, pfnSetDstRect = 0, pfnSetSrcRect = 0, pfnSetDstCKColour = 0,
pfnSetSrcCKColour = 0, pfnGetSystemBuffer = 0, pfnGetBuffers = 0, pfnSwapToBuffer = 0, pfnSwapToSystem = 0,
pfnGetSysBusAddr = 0, pfnGetCPULinAddr = 0, pfnGetSyncObject = 0, pfnLockBuffer = 0, pfnUnlockBuffer = 0,
pfnGetDevInfo = 0, pfnSetupMMAPFuncs = 0, pfnSetFlipCmdComplete = 0, pfnInstallISR = 0, pfnUninstallISR = 0}

PVRSRV_ERROR CreateSwapChain(IMG_HANDLE, IMG_UINT32, DISPLAY_SURF_ATTRIBUTES *, DISPLAY_SURF_ATTRIBUTES *, IMG_UINT32,
IMG_UINT32, IMG_UINT32 *, IMG_HANDLE *);
PVRSRV_ERROR DeInitDevice(IMG_HANDLE);
PVRSRV_ERROR DestroySwapChain(IMG_HANDLE, IMG_HANDLE);
PVRSRV_ERROR EnumerateDims(IMG_HANDLE, IMG_UINT32 *, DISPLAY_FORMAT *, DISPLAY_DIMS **);
PVRSRV_ERROR EnumerateFormats(IMG_HANDLE, IMG_UINT32 *, DISPLAY_FORMAT *);
PVRSRV_ERROR GetBuffers(IMG_HANDLE, IMG_HANDLE *);
PVRSRV_ERROR GetCPULinAddr(IMG_HANDLE, IMG_CPU_VIRTADDR *);
PVRSRV_ERROR GetDeviceInfo(IMG_HANDLE, DISPLAY_INFO *);
PVRSRV_ERROR GetDisplayJumpTable(DISPLAY_CLASS_JUMP_TABLE *);
PVRSRV_ERROR GetSyncObject(IMG_HANDLE, PVRSRV_SYNC_INFO **);
PVRSRV_ERROR GetSysBusAddr(IMG_HANDLE, SYSTEM_ADDR **);
PVRSRV_ERROR GetSystemBuffer(IMG_HANDLE, IMG_HANDLE *);
IMG_HANDLE InitDevice(IMG_HANDLE, PFN_INSERT_CMD, PFN_SUBMIT_CMD);
PVRSRV_ERROR InstallVsyncISR(IMG_HANDLE);
PVRSRV_ERROR LockBuffer(IMG_HANDLE, IMG_HANDLE, IMG_RECT *, IMG_UINT32, IMG_CPU_VIRTADDR *, IMG_INT32 *, IMG_UINT32 *);
IMG_UINT32 MapSysPhysToDevPhysAddr(SYSTEM_ADDR *);
PVRSRV_ERROR SetDstCKColour(IMG_HANDLE, IMG_HANDLE, IMG_UINT32);
PVRSRV_ERROR SetDstRect(IMG_HANDLE, IMG_HANDLE, IMG_RECT *);
PVRSRV_ERROR SetFlipCmdComplete(void);
PVRSRV_ERROR SetMode(IMG_HANDLE, SYSTEM_ADDR *, DISPLAY_MODE_INFO *);
PVRSRV_ERROR SetSrcCKColour(IMG_HANDLE, IMG_HANDLE, IMG_UINT32);
PVRSRV_ERROR SetSrcRect(IMG_HANDLE, IMG_HANDLE, IMG_RECT *);
PVRSRV_ERROR SwapToBuffer(IMG_HANDLE, IMG_HANDLE, IMG_UINT32, IMG_RECT *, IMG_UINT32, IMG_HANDLE);
PVRSRV_ERROR SwapToSystem(IMG_HANDLE, IMG_HANDLE);
PVRSRV_ERROR UninstallVsyncISR(IMG_HANDLE);
PVRSRV_ERROR UnlockBuffer(IMG_HANDLE, IMG_HANDLE);
static PVRSRV_ERROR CreateSwapChainDevInfo(OMAPLCD_DEVINFO *, IMG_UINT32, IMG_UINT32, OMAPLCD_SWAP_CHAIN *,
DISPLAY_SURF_ATTRIBUTES *, DISPLAY_SURF_ATTRIBUTES *, IMG_UINT32 *);
static PVRSRV_ERROR DestroySwapChainDevInfo(OMAPLCD_SWAP_CHAIN *);
static void Flip(OMAPLCD_DEVINFO *, long unsigned int);
static void FlushQueue(OMAPLCD_DEVINFO *, void (*)(IMG_VOID *, long unsigned int), IMG_VOID *);

and
(gdb) print *psDisplayJumpTable
$11 = {pfnInitDevice = 0x400717e0 <InitDevice>, pfnDeInitDevice = 0x40071bcc <DeInitDevice>,
pfnEnumerateFormats = 0x40071d58 <EnumerateFormats>, pfnEnumerateDims = 0x40071e50 <EnumerateDims>,
pfnSetMode = 0x40071f74 <SetMode>, pfnCreateSwapChain = 0x40072048 <CreateSwapChain>,
pfnDestroySwapChain = 0x40072618 <DestroySwapChain>, pfnSetDstRect = 0x400726f8 <SetDstRect>,
pfnSetSrcRect = 0x4007277c <SetSrcRect>, pfnSetDstCKColour = 0x40072800 <SetDstCKColour>,
pfnSetSrcCKColour = 0x4007286c <SetSrcCKColour>, pfnGetSystemBuffer = 0x400728d8 <GetSystemBuffer>,
pfnGetBuffers = 0x40072944 <GetBuffers>, pfnSwapToBuffer = 0x40072a0c <SwapToBuffer>,
pfnSwapToSystem = 0x40072c14 <SwapToSystem>, pfnGetSysBusAddr = 0x40072dd4 <GetSysBusAddr>,
pfnGetCPULinAddr = 0x40072e4c <GetCPULinAddr>, pfnGetSyncObject = 0x40072eb8 <GetSyncObject>,
pfnLockBuffer = 0x40072f78 <LockBuffer>, pfnUnlockBuffer = 0x4007315c <UnlockBuffer>,
pfnGetDevInfo = 0x40072f24 <GetDeviceInfo>, pfnSetupMMAPFuncs = 0x400736e4 <SetupMMAPFuncs>,
pfnSetFlipCmdComplete = 0x40073190 <SetFlipCmdComplete>, pfnInstallISR = 0x400731ac <InstallVsyncISR>,
pfnUninstallISR = 0x40073204 <UninstallVsyncISR>}

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

where is the video

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

For those still following, I just had ./xovgtest working on my N8x0 (OpenVG). Stalls after a little bit, but progress..

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

Here is Mitrandir's video m.youtube.com/watch?gl=US&warned=True&client=mv-google&xl=xl_blazer&hl=ru&xl=xl_blazer&v=qVeEDhWtH 8o

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

Fixed URL: http://www.youtube.com/watch?xl=xl_b...&v=qVeEDhWtH8o
It is jumpy

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

Opera mobile always become freezed when I try to change youtube.com to PC mode so this is why I posted mobile linlk.

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

There hasn't been any new information about the driver for a while. Is someone still working on it?

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

I only know stskeeps is no longer being paid to work with maemo. If someone can step up, and continue with his work that would be great.

We don't need great 3D performance, just GL compatibility so we can adapt MeeGo to work on N8x0.

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

I continued the work even after not being paid to do it, just fwiw. It works, but it causes a hardware recovery quite often, ie, stalls.

The problem is the drivers, it looks like and I haven't had success figuring out why it does HW recovery all the time.

Re: Yes, the N8x0 has a 3d accelerator, now how do we make it work?
 

Thanks. Is this a blocker to MeeGo adaptation?