No direct video buffer access on WM2003 Second Edition

[Guest The PocketTV Team]

GAPI documentation here: http://msdn.microsoft.com/library/default....htm/gx_hjwu.asp

In case you want to check what GAPI is before talking about it :D

Again, GAPI and PocketHAL are out of topic here. But some people don't understand (yet)...

[Guest SpaceRain]

I know EXACTLY what GAPI is, so if you're talking about me, then please let me know, so I can be offended. :)

[Guest The PocketTV Team]

That he could do things faster with GDI than with GAPI.

Read the GAPI manual: GAPI does *nothing*.

So you cannot compare GDI with GAPI.

That's not the point.

The point is being able to access the raw frame buffer directly.

[Guest The PocketTV Team]

I know EXACTLY what GAPI is, so if you're talking about me, then please let me know, so I can be offended. :D

Then why do you talk about comparing the time to draw with GAPI ????

Since GAPI cannot draw, you must use something else to draw.

So that's what you are comparing with GDI.

GAPI is not part of the equation.

And if you are trying to tell me that you can go faster with GDI than by direct access to the buffer... well, since GDI does lots of layer before eventually accessing the raw buffer directly, if you remove some layer and do the same thing, them you're likely to be faster.

[Guest The PocketTV Team]

Anyway, I'm tired of arguing. Either you care about the issue I raised, either you don't.

If you don't, or you just want to go off-topic, stay out of this thread, please.

[Guest spacemonkey]

For XXXXs sake.

The issue.

Windows Mobile 2003 SE doesn't have gapi. What this means is that you can't conveniently get the RAW graphics memory address.

Now there are other solutions to get the RAW address however, as found be people elsewhere this memory can change unexpectedly due to the auto orientation hardware and software in 2003 SE.

So the reason microsoft haven't included GAPI is because they know direct access to the framebuffer will be a bad thing because of this issue.

This doesn't mean that developers will never again be able to use video memory directly, or that we'll be stuck with GDI. This means microsoft thought of something cool (dynamic automated screen rotation) and when they got it to market hadn't thought through and implemented all the tools/issues related to that change.

Ultimately I imagine that if a developer wants to use the raw memory access then they'll need code to trap and resolve orientation related issues on the fly, potentially even with a screen update cycle.

The people who need to fix this are microsoft. Something like PocketHAL will resolve the lack of GAPI, however it won't resolve the underlying problem which has caused microsoft to leave GAPI out.

[Guest The PocketTV Team]

I know EXACTLY what GAPI is, so if you're talking about me, then please let me know, so I can be offended. :D

I was talking about Arisme.

I agree with what you say, SpaceRain, sorry for the confusion there!

[Guest SpaceRain]

Hahaha, I DO find it surprising that he could do his graphics faster through the GDI than by using direct access to the video memory as provided by GAPI. :)

And that's anything but off-topic, as this thread is about GAPI possibly not working on some 2003 SE devices. It's only natural to discuss what we're gonna do without GAPI. :)

[Guest The PocketTV Team]

As long as we have a replacement that works, no problem. GETRAWFRAMEFUFFER works in some cases, but it still breaks on some Pocket PC's.

We have an example of a device where nothing works, really... even though GETRAWFRAMEFUFFER is implemented. See http://www.pocketpcthoughts.com/forums/vie...p=233239#233239 .

[Guest Arisme]

Oh, I think it's quite simple : the E800 GDI blitting code is optimized for the E800 video hardware. My GAPI blitting code is not optimized at all, even less for the E800 hardware - thus GDI is faster, especially when it needs to copy a large amount of data :wink:

A more interesting test would be to use an highly (generic ARM optimized) API such as GAPIDraw, and see if the same GDI blit is still faster. I guess it probably will. But things will probably be different with a specific hardware optimized API such as PocketHAL.

(hoping this post will get Mr PocketTV seal of quality, or at least be ignored to let me exchange puny ideas with my fellow inferior beings ... crossing fingers :D)

[Guest The PocketTV Team]

> Oh, I think it's quite simple : the E800 GDI blitting code is optimized for the E800 video hardware. My GAPI blitting code is not optimized at all, even less for the E800 hardware - thus GDI is faster, especially when it needs to copy a large amount of data

In that case, yes, it is possible.

> A more interesting test would be to use an highly (generic ARM optimized) API such as GAPIDraw, and see if the same GDI blit is still faster. I guess it probably will.

That's definitely not sure. In PocketTV, we are much faster using our own optimized routines rather than GDI, even on the e800. We are *much* faster.

[Guest Arisme]

that'd be something interesting to know (assuming you're not talking about ATI proprietary optimizations, of course, otherwise it's not fair :D) ... before these "new generation" PDAs, even a poorly implemented GAPI blitting was way faster than a GDI blit.

getting back on topic, regarding the "rotate screen" button issue, is it still active when using GAPI input ?

[Guest The PocketTV Team]

that'd be something interesting to know (assuming you're not talking about ATI proprietary optimizations, of course, otherwise it's not fair  :D) ... before these "new generation" PDAs, even a poorly implemented GAPI blitting was way faster than a GDI blit.  

getting back on topic, regarding the "rotate screen" button issue, is it still active when using GAPI input ?

No, I was not talking about using that ATI surfaces for hardware-acceleration. I was just talking about writing the RGB data (calculated by software) into the raw RGB 16-bit frame buffer.

[Guest schriss]

The PocketTV Team: can you comment on nVidia GoForce 2150?

http://msmobiles.com/news.php/1961.html

"The processor handles pictures as large as 1.3 megapixels, outperforms the Nintendo Game Boy Advance graphics by a factor of 25, consumes little battery power and supports 70 different display interfaces to ensure it can be used in a wide variety of devices"

I'm soon to be a MiTAC Mio 8390 owner, that's why I'm interested :D

[Guest roozbeh]

a question here:

how does gdi draws?for sure they do write in frame buffer and so they know the address...so getting that addres on diffrent devices must be implemented and also why they havnt make that function public for use?

and peaple have to use gapi for drawing?

[Guest The PocketTV Team]

> how does gdi draws?for sure they do write in frame buffer and so they know the address...

For sure ? How do you know ?

Maybe DGI calls a driver routine and tells the driver to draw a bitmap at some (x, y) coordinates in the frame buffer. Maybe GDI does not know the address of the raw frame buffer (in fact, I think that's the case).

There are certainely many video driver routines used by GDI, but they are not publicly documented. You can look in the Platform SDK documentation if you want to try using them.

[Guest schriss]

What I meant by my question above is if we can recompile Doom or Quake Smartphone port to take advantage of GoForce 2150 in Mitac 8390 and make it run much faster :D

[Guest schriss]

OK, I found it for you:

Documentation and Online Resources for NVIDIA GPUs (for example GoForce2150 found in Mitac Mio 8390)

NVIDIA Handheld SDK (March 2004)

http://developer.nvidia.com/object/hhsdk_home.html

There are examples, Handheld Demo Wizard, etc.

I found out that 2150 is 64bit 2D graphics engine, it has double buffered frame buffer, hardware DCT, RLE, Huffman encoding, hardware JPEG encoder, hardware display rotation, mirror, flip, etc.

Graphics acceleration includes: BitBLT 256 3-op raster operations, rectangle fill, all angle line draw and others.

I would be awesome to see PocketTV and others taking advantage of this! :D

[Guest schriss]

It appears PacketVideo's pvPlayer already takes advantage of this hardware :D

http://www.nvidia.com/object/IO_9221.html

"In initial tests, the optimized pvPlayer running on MediaQ's MQ-1168 accelerated video decoding to run up to three times faster (as measured in frames per second) than CPU-only handheld hardware solutions." ;)

[Guest schriss]

Looks like pvPlayer has been pulled off...

But I found it here:

http://www.slunecnice.cz/product/PVPlayer/

:D

Who is going to try it first? ;)

[Guest schriss]

Looks like it's for Windows CE :cry:

[Guest roozbeh]

Maybe DGI calls a driver routine and tells the driver to draw a bitmap at some (x, y) coordinates in the frame buffer.  Maybe GDI does not know the address of the raw frame buffer (in fact, I think that's the case).

There are certainely many video driver routines used by GDI, but they are not publicly documented.  You can look in the Platform SDK documentation if you want to try using them.

well so drivers know the addres and so there is a way to communicate with them and also in the worse way you can call series of putpixel routines to draw the whole frame buffer at that address...

i mean it only need to change GAPI to work correct with that version.....

why you can not think of another version of gapi for wm2003se?

but the only thing i dont get is that how they want to fit programs of older version in that bigger screen size?

[Guest The PocketTV Team]

> well so drivers know the addres and so there is a way to communicate with them

Yes: GAPI (on Pocket PC 2003 and earlier) and GETRAWFRAMEBUFFER (on WM2003-SE).

If the video driver does not implement GETRAWFRAMEBUFFER, you'll have to guess the address, or do some reverse engineering.

> and also in the worse way you can call series of putpixel routines to draw the whole frame buffer at that address...

??? you must be kidding, right ?

> i mean it only need to change GAPI to work correct with that version.....

> why you can not think of another version of gapi for wm2003se?

Yes, it's called GETRAWFRAMEBUFFER. This is what replaces GAPI on WM2003-SE. GAPI is still there but it is not usable.

[Guest roozbeh]

no i am not kidding...it will become very slow and not usable but well it IS the workaround...well maybe the worst......

and well if that GETFRAMEBUFFER is the only way so OEMS will for sure implement it..there is no way to worry that much....

although the second bug you mentioned is bad(that for switching screen)..and i dont think this GAPI is anymore an issue....

[Guest SpaceRain]

I did some simple tests with PocketHAL, GAPI and the GDI on my E200, and here are the results:

Redrawing the entire screen in a random color WITHOUT backbuffer:

GAPI: 130 fps

PocketHAL: 93 fps

GDI: 69 fps

PocketHAL is actually using backbuffer here too (so is GDI), that's why it's slower than GAPI, but it can't be disabled. So, if you don't need a backbuffer, GAPI is a much faster choice.

Redrawing the entire screen in a random color WITH backbuffer:

GAPI: 93 fps

PocketHAL: 93 fps

GDI: 69 fps

GAPI and a memcpy() is exactly the same speed as PocketHAL. So much for "device dependent optimizations", eh? It might be faster on other devices, of course, but on my E200, even copying the entire backbuffer to the screen takes exactly the same amount of time whether you use GAPI and a memcpy() or PocketHAL.

Taken from the website: "Synchronization with the VSYNC signal to eliminate tearing (available on most devices)." My E200 apparently isn't one of those "most devices", either. PocketHAL is drawing all over the screen, so it looks exactly as bad as GAPI. The website also states that if the VSYNC signal isn't available on the device, PocketHAL will attempt to minimize tearing. Well, like I said, it looks exactly the same as GAPI. :)

All tests were carried out over 10000 drawn frames. PocketHAL might of course do other stuff faster, that wasn't tested here, but even the backbuffer copy isn't faster at all.