Intel Graphics Performance Primitives library

[Digby]

I attended an Intel 3D Graphics for XScale talk today at the Game Developer Conference in San Jose. Intel released a beta of their Graphics Performance Primitives on their website this week. Although they state that this is for their two new XScale chips, it will work on a StrongARM.

[Jim]

[Conan]

[Jim]

[Digby]

The Intel engineer assured me it would work on StrongARM, and he showed a few demos running on an iPaq 3650.

I haven't tried to install it myself as I'm out of town with only a 33K modem connection in my hotel. If no one can install this, I'll track down the Intel engineer and ask him if he's aware of any problems.

[Conan]

[Digby]

OK, I've downloaded the software and I have the same problem on my XP notebook here (Program too large to fit in memory). Just on a hunch, I renamed the executable file as .zip and opened the file as if it were a zip archive. Works like a champ. Run the exe in the zip archive and let me know if you continue to have problems. I'll let the Intel guys know they have a problem with the naming of the file.

[simonjacobs]

[Digby]

The library is a collection of primitive routines that you would use to write your own 3D API. As far as the texture mapping goes, it only supports RGB565 textures, texture coordinates are 16.16 fixed-point, and it supports additive, modulate, and decal style blending. As far as I can tell it only does point-nearest texture sampling and does not support perspective-correction. The rasterization APIs are implemented not as polygon or triangle based routines, but scanline based.

[Conan]

[Dan East]

[Dan East]

Well, it's been 8 months. So has anyone made use of this library? How about some benchmarks? How is the performance on StrongARM compared to XScale?

Dan East

[Dan East]

I am trying to evaluate the IGPP library. However I have found that the documentation is terrible. The library contains no samples, and the internet appears to be void of any technical discussion of the library. The documentation does not indicate the precision to be used for any of the struct members used by the rasterizers (they appear to be 16.16 for the x values). Another example is GPP_RASTER_PARAMS::m_rgba. The docs simply state "denotes the object color (used for flat shading)". The actual format by trial and error is an rgb 565 followed by a short for the alpha (is the alpha fixed point 8.8, or is it integer? what's the range, etc). The docs do not specify the acceptable ranges for values, or what clipping is performed.

Has anyone had any success in using this library? I have gotten it to render flatshaded polys, but it appears to be rendering very far past the end of the line in some cases, overflowing my buffer.

I'm just really surprised that Intel would invest money to have someone create such a library, and release poor documentation and not a single shred of source code or actual usage information.

Dan East

[Digby]

The docs do say that the functions act on color values in 5-6-5 format. Which of their functions actually perform alpha test/blending? I looked over the Rasterization section of their docs and none of them mentioned alpha blending.

Think about this... In most 3D APIs, a value of zero for the alpha channel denotes transparency. There is no method (as least not in the docs) to enable/disable alpha blending, so you're assuming it's always on. OK, so if you only set the 5-6-5 values of that U32 color value for your polygon, the alpha would be zero (transparent). If alpha ere always on, then all of your scanlines would not show up in the frame buffer. But they do! I'm willing to bet that alpha blending isn't supported in the current version of this library.

You could try sending e-mail to the guy who was in charge of the team that wrote it:

gopi.k.kolli@intel.com

[Dan East]

The vertex struct (GPP_TLVERTEX_V2F_C4F_T2F) allows you to specify the alpha. I thought I read that it supported it, but after checking I don't see any raster routines that mention it.

I was able to get IGPP rendering in texture mode, but never got the UV right. However the performance should be the same whether or not the UV was 100% correct. I saw marginal, if any, performance improvement over my existing software routines. I was going to have to use my own routines anyway for polys requiring perspective correction.

BTW, check your email.

Dan East