Orange SPV supported?

Is the Orangle SPV supported by OpenGL ES(the “old SPV”, not the new SPV 200) ?

If no, someone want to help me to make one implementation of an OpenGL ES lib/SDK for the Orangle SPV ?

Yep. I can probably help you getting Vincent running on this device. Personally, I own only Windows Mobile 2003 devices, but bringing the library to Smartphone 2002 should be mainly a matter of recompiling with corresponding compiler settings.

Drop me a note if you are interested. Do you have a Sourceforge account?

  • HM

What’s about the necessary software needed for devellop on Windows CE 2002 ???

I’m very more familiar with GNU software (such as GCC on Linux or WinGW on Windows) that others environnements such as Micro$oft .NET products …

Have I to buy Visual C++ .NET for devellop for a Windows CE 2002 plateform or can I make the same thing using GCC and others derivates ?

I have see that you use something like JIT compilator for the scanline code generation, have I to have one JAVA environnement on my SPV ? If yes, where can I find “the good JAVA implementation” on the Web ???

You can download eMBedded Visual C++ for free. In there references on my site, I have also a link to a developer tool CD that you can order; you basically pay for shipping and handling.

The JIT is part of the library, so you won’t need a JVM. The main “real” development work should be the replacement of the Intel GPP library with arithmetic (division, square root, etc.) that run on the phone’s processor. I should be able to help you with that.

  • Martin

[ April 14, 2004: Message edited by: Hans-Martin Will ]

Thanks, I download all this in some hours in my house and see a little this more in detail during this night.

I think really to begin the “real work” in some days, after to have see a little more the Vincent’s sources and others similars sources (such as KLIMT that seem to make about the same thing) and testing how work the Windows CE 2002 compilation for the SPV plateform (and work on the float2integer conversion seem effectively to be a good start for my case :).

Now that I have installed the Micro$soft eMbedded Visual C++ 3.0, download some things like the Vince’s release, the GAPI and other 2D/3D related library for smartphones and pocket PCs, test somes basics compilations for my specific target (Orange SPV, Smartphone 2002 version 3.0 build 12255, ARM720, ROM 1.3.6.5) and browse a little all this, it’s now a little more clear …

Why operate pixel per pixel for the scanline generation and not span per span like MESA ?

It’s for limit the library size (cf. minimise the explosion of the number/size of scanline funcs) ?

I have to install the NVIDIA Cg language too(I have see cg_ funcs into the JIT compilator sources …) ?

Or perhaps “pixel per pixel” + “CG shader” + “JIT scanlines compilation” features are more linked that I can think ?

And what do you think about the complexity of a RenderMan-like interface ? After all, my SPV can already display MPEG, DivX and others WM$ video files, so why not dream a little about things like raytracing and/or radiosity on my SPV ? :slight_smile:

Obviously I need to work on the design documents at some point… :slight_smile:

Pixel per pixel (Fragment(…) ) is the “interpreted” version of fragment processing, and you are right, this is very inefficient. It is, however, not used when you render triangles, but is more a personal reference implementation of all the options necessary for full fragment processing. It is still being used for point and line rendering, as performance has not been a priority yet.

The problem with efficient software rasterization is that there is a huge number of combinations of GL state settings that affect what computations need to be executed and what not.

The early versions of Klimt tried to address this by generating scanline function for all supported combinations of parameters (back then ~700), which resulted in a library 1.5MB in size and still not supporting all settings required by the OpenGL ES spec. To give you an idea, a basic coverage test of all options yields thousands of combinations.

MESA, and the new rasterizer in Klimt introduced around Christmas, take the approach of breaking the full fragment processing into phases. Think of “get texture data”, “apply texture modulation”, “blending”, “logic op” etc.

For each of these phases, a separate function is created for specific parameters applicable to this phase. The total number of functions is significantly lower. However, you get all the function call overhead because you need to chain these phases together. In order to reduce this overhead, in turn, each of these functions works on a scanline per scanline basis. E.g. “get texture pixels” will retrieve all the pixels for the current scanline, blending will perform blending for all the pixels in the scanline etc. For Klimt, the most common cases of scanlines are captured in single functions, BTW.

Besides the fact that you have to go through the function prolog and epilog, where you really loose is in register allocation, because each function call acts as a heavy constraint.

Yet, especially for more complex settings, the computation is sub-optimal. For example: You have a texture with alpha channel, but you do not use this value; no need to fetch it from memory in the first place. If your depth test fails, large parts of the computation can be skipped for the corresponding pixel, etc.

This is the idea for JITting, i.e. creating the scanline function on the fly on an as-needed base: You attempt to achieve the optimality of having an optimized version for each combination of parameters, yet you conserve memory because most “real” programs (obviously not the conformance test), exercise only a small subset of possible combinations. Notable commercial Open GL (ES) implementations using this approach for software rasterization are Microsoft’s desktop OpenGL (when no hardware is present) and Hybrid’s implementation (link on this web site).

What the cg_… functions (“cg” for code generator; nothing to do with NVidia) provide is basically an optimizing compiler backend. If you look into CodeGenerator.cpp/GenerateFragment(…) then you’ll see that this is a version of Fragment(…) where the original code became comment, and the actual code executed submits instructions to this compiler backend based on the current GL state settings.

The compiler backend then analyzes this intermediate representation to remove any unnecessary code, find instructions that can be combined, and determines conflicts between registers and what registers should be allocated gloablly for what range. With all that information determined, a scanline function is finally generated.

Does this give you a better picture what’s going on?

  • Martin

PS: Sweet dreams… :slight_smile:

[ May 02, 2004: Message edited by: Hans-Martin Will ]

Thank for alls yours infos on your precedent email :slight_smile:

Heu … how this work for triangles ?
It’s make via the Intel library ???

Escuse-me for my precedent email, I have now see the triangle rasterizer files :slight_smile:

So I can now really begin to implement something such as some fixed point sinus and cosinus funcs for my SPV …

For the math functions: I helped another user to replace these functions with C functions yesterday. I do not want to check these changes in without full testing, but if you contact me by email, I can send you the patch.

  • Martin

Just for the record: Klimt also runs on the Orange SPV… :slight_smile:

Daniel

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.