Search results

This is great news. Based on what i've done with my math-neon tests runfast gives maybe 10 - 20% improvement, so if that was noticeable NEON optimisation should be fairly significant. I get a 1000% improvement for NEON 4x4 matrix matrix mul and about 600% improvement for matrix-vector mul...

Yep, I've got 2/3/4 element matrix-matrix mul and matrix-vec mul. I've been testing them recently, 4x4 matrix-matrix mul is about 11x faster and 2x2 matrix-matrix mul about 4x faster than the c implementations (with runfast enabled + all compiling flags). I will also be implementing the vector...

Upon further inspection, I think glN64 already has this option under WIN32. We could probably port it to SDL_threads pretty easily.

Thanks, It's more that I've already written and tested NEON-ized 2,3 & 4 dimension matrix-matrix mul and matrix-vector mul for the math-neon project. So i should be able to just drop them in with very little modification. Some profiling would be great. Here's some simple tests that could be...

I feel slightly cheated :). Congrats. What the hell. That's all it was... Wow. Now the hard part begins. I will be adding NEON optimisations to gles2n64 soon, that might improve the speed. I think with frameskip, this will be very playable. I'm not sure whether the graphics plugin or the...

ES 2.0 require precision specifiers on all attrib/uniform/temp declarations except scalars/texunits. Apart from the lack of most inbuilt uniforms/attribs and the ftransform() function its pretty much the same or better. I think they're talking about the libraries for GLES development on...

Yea I'm a bit unsure about this. One thing i know is OGLES2 doesn't support writing to the depth buffer in the fragment shader, It also doesn't support glReadPixel() with GL_DEPTH_COMPONENT. However the raw FBO support is actually quite good (assuming there isn't any bugs). I'm not sure how...

Yes i know, perhaps i was a bit harsh. I also tend to say stupid things. That appears to be the plugins fault. I was logging the commands for awhile and there was a huge number of grDrawTriangle calls without any state changes inbetween. If they're supported on the hardware your targetting, I...

Sorry, i didn't mean it to come out that way, i wasn't intending to argue. I was just saying that my functions exhibit the same fallacies as cmath, just a little bit more exaggerated. I have nothing against cmath, its a good, fast general computing library. The fact that it handles doubles is...

If you were relying on cmath for a high accuracy, scientific application you would have to be pretty stupid. My algorithms are in general not significantly less precise than cmath. For instance the cmath implementations i've seen of sinf have a peak absolute error of ~3.0e-7, as you can see...

Thats the idea of the library. If you want cmath like accuracy for many functions you need significant branches to subdivide the range, each of which cause a >20 cycle NEON & ARM stall. Also remember that this is simply relative peak error (as a percentage) over the range I've specified, in...

This is pretty surprising. I compiled my library on a X86 C2D 2.0Ghz XP machine and some of my *_c functions are significantly outperforming the inbuilt ones. Maybe there's some other platforms that this library will be useful for. Here's the results: Function Range Number Max Error Rate...

I'm linking to libm.so.6 Yeah, The compiler supports it... kind of. It compiles the individual objects fine, but when it links them it says that your program doesn't use VFP arguments. I vaguely remember someone saying it's because libgcc / libc were compiled with softfp....

I think it purely because my testing code uses a few float operations, like this: for(float x = x0; x < x1;x += dx) (*func)(x). I have to test over a decent range because the inbuilt functions sometimes have branches that optimize for certain cases. Thats a good point, i did add a macro for it...

Well I've just spent my first weekend with a devkit, was an interesting ride. Since it has almost zero dependencies the first task i set myself was to get my math-neon project up and running. Heres some tests with the SoftFP abi: RUNFAST: Disabled Function Range Number Max Error (%) Time...

At the moment, The GLESv2 functions are dsym'ed, the EGL functions are not. This is because you must get an EGL context before you call any gl* functions like those in wes_init()->wes_shader_init() etc. You should be able to just link the EGL functions via libEGL.a on the pandora (however you...

Seemed to work for me, but i only played a few min. Maybe its because I'm using the original Mupen64. Either that or its because your linking with libOGLESv2.a even though i'm dynamically linking in gl-wes-v2. On the emulator, I have to do this because the EGL functions are actually within that...

Ummm, Just thought i should mention that I've began the glN64 port. You can find the sourcecode here: http://code.google.com/p/gles2n64/ What I've done: - Ported to gl-wes-v2. - Significantly debugged gl-wes-v2. - Added optimisations to fragment shader generation. - Added relevant ATI and NV...

I would assume the shader compiler is already doing those optimisations but i may be wrong. Obviously, I'll focus on getting it running first....

Ahhh right. Sorry for the confusion, as usual i missed the point by a big margin. I guess i could gain performance since multipass combiners would become singlepass, but i would like to know how often these actually occur first....