Dell Axim X50v with Intel2700G

K

Kristof

Regular
Supporter
Launched today :

Dell Axim X50v

Intel® XScaleTM PXA270 624MHz
Microsoft® Windows MobileTM 2003 Second Edition
Windows Media Player 10 Mobile
RAM: 64MB SDRAM
ROM: 128MB Intel StrataFlash® memory
TFT Color 16-bit, Touch Sensitive, Transflective LCD
3.7 inches
480 x 640 resolution at 65,536 colors (VGA)
Intel® 2700G multimedia accelerator with 16MB video memory

FREE 3D Gaming Pack with Axim X50 purchase comes with:
Head to Head to Action with StuntCar Extreme
3D Puzzles with Enigmo

K-
 
I find it strange that Dell don't make any mention of the 3D capabilities of the chip in their advertising. Obviously, 3D might not be the main reason that anyone buys this type of PDA but it's always a good advertising buzzword. Almost seems as though they are underselling the product. :?
 
does any one know why the 2D acceleration is so bad ? and can it be rectified? many people seem to be saying it because of some GAPI driver thing. So can it be rectified easily like with a patch or something?

I was looking forword to buying this pda, but if it performs so bad in graphics , i will not buy it.
 
Here's another review:

http://www.aximsite.com/articles/link.php?id=200

An excerpt from this review:

Let me interrupt our viewing of benchmarks by saying that something seems skewed with all the graphic benchmarks I attempted. It seems that none of these methods take advantage of the graphics acceleration that is built into the Intel 2700G Chip. I can say that the screen seemed as fast as a QVGA Screen to me. Further testing will be done as methods are available.
Click to expand...
 
sounds like the same old story - the original Axim used an 'xscale' video chip that supported all sorts of lush blitting, there were white papers and demos but nothing was ever supported by the OS so what was the point ....
 
sounds like the same old story - the original Axim used an 'xscale' video chip that supported all sorts of lush blitting, there were white papers and demos but nothing was ever supported by the OS so what was the point ....
Click to expand...
This sort of thing seems to happen a lot and really suprises me, kind of like ATI with its fbuffer, lots of talk and the hardware is there but no software support to acutally be able to use it. :?

So now theres at least a few PDAs with 3D support, does anyone know if there are any cellphones with built in 3D chips yet? Now that would be neat. :D
 
[quote="GoragothSo now theres at least a few PDAs with 3D support, does anyone know if there are any cellphones with built in 3D chips yet? Now that would be neat. :D[/quote]

They're coming 8)
 
hrishi2das said:
does any one know why the 2D acceleration is so bad ? and can it be rectified? many people seem to be saying it because of some GAPI driver thing. So can it be rectified easily like with a patch or something?
Click to expand...
Sounds like the application may not be making use of all the HW (i.e. not using the right API?) <shrug>. I believe all the needed 2D support is in HW in the graphics chip.
 
hrishi2das said:
does any one know why the 2D acceleration is so bad ? and can it be rectified? many people seem to be saying it because of some GAPI driver thing. So can it be rectified easily like with a patch or something?

I was looking forword to buying this pda, but if it performs so bad in graphics , i will not buy it.
Click to expand...

From the Intel whitepaper on this matter :

Since graphics acceleration capability in handheld devices has historically been limited, there has not been a need for advanced graphics APIs. In this type of environment, applications and tests have resorted to updating the display image by directly writing to the frame buffer’s memory location. There are a variety of ways that this can be done (for example, using legacy GAPI, GetRawFrameBuffer, etc.), which will collectively be referred to here as direct frame buffer accesses, or DFBs.

DFBs are an easy way to modify/test graphics in an un-accelerated system. However, DFBs are severely limited in capability, especially when compared to advanced graphics APIs like OpenGL ES. While advanced graphics APIs allow applications to be written that take advantage of accelerated graphics capabilities (if they are available), DFBs do not. DFBs have no comprehension of a system’s graphics acceleration capabilities, whether they are hardware-based (as with Intel 2700G) or software based (driver optimizations). As a result, DFBs completely avoid any acceleration benefits that the system can provide.

Tests that are based upon DFBs do not accurately measure graphics performance. What they do accurately measure is the bandwidth between the CPU and graphics memory. This was a somewhat useful graphics metric for systems that did not contain a graphics accelerator, and relied upon the CPU to update the frame buffer. However, this is not a useful metric in systems that incorporate dedicated HW acceleration – where a graphics component, and not the CPU, is most responsible for updating the frame buffer.
Click to expand...

Whitepaper is available from Here.

K-
 
Summary:

We have now this new and better PDAs with VGA, but only new applications that are write for the new APIs would run perfect.

If we use an old application we must expect that it will be slower on the new faster device as on the most old one?
There is no way to change this? Kristof? :)
 
Dunno really, I am not a 2D man. I'd guess it depends on how these old APIs work and if they can actually be wrapped into using the new HW functionality... but as said in the whitepaper if these APIs just allow direct memory access then it might be quite tricky to do since its really like reading/writing directly into video memory using the CPU pixel per pixel. I think using glWritePixel/glDrawPixel/glReadPixel in OpenGL on desktop implementations is similarly "very" slow.

Possibly an option is to do it all on the CPU side (as old systems do) and then have a single accelerated blit to the video memory at the end ? But as said I am no 2D expert just making guesses...

K-
 
One of the problems with DFB's is that they don't mix well with hw acceleration. As soon as you have direct framebuffer access on a system with hw acceleration you start having to synchronize operations. I.e. you have to wait for any outstanding hw accell operations to complete before allowing access to the surface, and vice versa.

The 2d benchmarks are probably going to go the same way as the PC market did, at first they were the big thing for marketing, and then eventually they realised that after a certain point it makes no difference to the user experience. What will make more of a user experience difference will be the playability of the games, and video performance.

Not sure about the various players mentioned in the reviews, but windows media player should be using some acceleration for mpeg2 and mpeg4.

CC
 
I had a quick peek at GAPI and its... welll... basically it allows you to begin and end, begin gives you a pointer to video memory and when you are done modifying that memory you call end... so its basically : here is the memory do what you like and let me know when you are done. This is good for to the metal software graphics but horrible for HW... I think the best you could do is implement GAPI on the CPU side as optimally as possible and then when end is called you do a single blit into video memory. Not ideal but really don't see any way to use HW acceleration with GAPI since there is nothing to accelerate.

All my 2c...

K-
 
Looks like the battery life is even worse then HPs 600mhz model (though not by much). At this pace PPCs will be catching up with laptop battery life soon -_-
 
@Kristof and Caption Chickenpants

Ok I understand. So we must life with this and hope there will be soon newer software versions without this problems.

Even this old benchmarks not so importent for me, if I can work with 2D all is ok why I need a benchmark in this field :D , where are your real benchmarks for the MBX or is there not a demo or so for MBX to show how a application will run with and without hardware support?
 
I just wonder if there is some sort of 3D driver control panel that enables the user to select things like texture filtering options, anti-aliasing levels, etc., ala desktop/laptop pc. I'm new to pocket pcs, so I'm not sure if this sort of configuration is done within a 3D application, in some sort of driver control panel, or anywhere at all. Could somebody clarify?

It would stink to have all these abilities like "free" FSAA available (w/MBX), when they can't be activated on command.
 
You must log in or register to reply here.

Similar threads

L
MBX Lite Tech Demos from Intel -- Axim X50v 2700G
Replies
6
Views
5K
Lazy8s
L
Back
Top