Pandora Sgx Driver Benchmarks

[paddy]

Those stats don't really impress me ,i hope the driver gets the full treatment
as i am currently playing quake 3 on the psp at 22/28fps - drops to 12fps when
all hell breaks loose.And well we already know quake 1 runs at a constant 60fps
on the psp and quake 2 runs at 30-40 fps.

I dont like to put against the psp but it's all i could think of at the time
but in light of those stats ,craig's vid looks minted and i would think
it was running at around 50-60fps and thats at a standard 500mhz so wow!

Paddy

 

[craigix]

Those stats don't really impress me ,i hope the driver gets the full treatment
as i am currently playing quake 3 on the psp at 22/28fps - drops to 12fps when
all hell breaks loose.And well we already know quake 1 runs at a constant 60fps
on the psp and quake 2 runs at 30-40 fps.

I dont like to put against the psp but it's all i could think of at the time
but in light of those stats ,craig's vid looks minted and i would think
it was running at around 50-60fps and thats at a standard 500mhz so wow!

Paddy

The Pandora is running it at over THREE TIMES THE PSP RESOLUTION.

 

[WizardStan]

Those stats don't really impress me ,i hope the driver gets the full treatment
as i am currently playing quake 3 on the psp at 22/28fps - drops to 12fps when
all hell breaks loose.And well we already know quake 1 runs at a constant 60fps
on the psp and quake 2 runs at 30-40 fps.

I dont like to put against the psp but it's all i could think of at the time
but in light of those stats ,craig's vid looks minted and i would think
it was running at around 50-60fps and thats at a standard 500mhz so wow!

The stats are benchmarked, and probably running at higher graphics settings than what will actually be used to play, especially when considering the PSP has a lower resolution than the Pandora.
But that's totally irrelevant, you weren't supposed to be impressed with the stats themselves, you were supposed to be impressed by the CHANGE in stats. Note how Quake2 went from 19.7 fps in X with the old driver to 40 fps in X with the new driver? There was a problem in the old driver that could make it slow, and now that problem is solved. This means there is no longer any reason for any program to require framebuffer mode, which means that that is no longer a valid excuse for killing X. Not needing to kill X in order to play a game is a good thing. That is what the stats show, that is what you're supposed to be impressed with, and that is what I am impressed with.

 

[paddy]

I really didn't take the resolution into acount so,WOW ..
and yep i did read that for the time being when the Pandora ships
that we would need to kill X before running games so with the new
X driver setup things are looking better already.

Will the new driver be setup when the Pandora ships or is it in
testing still, and prolly be an update later on ?

BTW Nice work Pickle ! and sorry for the blind error.

 

[MDave]

Oh boy, I don't think ZEQ2Lite (based on q3 engine) is going to run at an acceptable FPS, with it being higher in system requiremnts to Q3. Might have to make a dumbed down graphics version specific to the Pandora

 

[darkblu]

niiice!

would a kind soul provide the outputs from eglQueryString(EGL_EXTENSIONS) and glGetString(GL_EXTENSIONS) with the new drivers, please?

 

[Exophase]

niiice!

would a kind soul provide the outputs from eglQueryString(EGL_EXTENSIONS) and glGetString(GL_EXTENSIONS) with the new drivers, please?

Although this probably goes without saying.. seconded.

 

[ldesnogu]

I wonder what the impact on Q3 speed the interpreted VM has...

 

[Exophase]

I wonder what the impact on Q3 speed the interpreted VM has...

Could you clarify what you're referring to?

 

[ldesnogu]

I wonder what the impact on Q3 speed the interpreted VM has...

Could you clarify what you're referring to?

I mean this: http://en.wikipedia.org/wiki/Quake_III_Arena#Virtual_machine

Given there's no ARM back-end all QVM files are interpreted.

 

[MDave]

I wonder what the impact on Q3 speed the interpreted VM has...

Could you clarify what you're referring to?

I mean this: http://en.wikipedia.org/wiki/Quake_III_Arena#Virtual_machine

Given there's no ARM back-end all QVM files are interpreted.

Not if the game code has been compiled into dynamic libraries (.so files) and the following cvars are set: vm_game 0 vm_cgame 0 vm_ui 0

This is the case because ARM isn't supported for virtual machine.

Quake3 can run 3 ways, they are

vm_game 0 vm_cgame 0 vm_ui 0: run via the native dll or .so qagame*.dll/so. Fastest, but most mods aren't compiled into these.

vm_game 1 vm_cgame 1 vm_ui 1: run via the interpreter. Slow and buggy, won't work for most mods.

vm_game 2 vm_cgame 2 vm_ui 2: compile qagame.vm to native processor architecture at run time. What a lot of mods and what the default is for Quake 3 on x86 and other supported platforms.

 

[ldesnogu]

Not if the game code has been compiled into dynamic libraries (.so files) and the following cvars are set: vm_game 0 vm_cgame 0 vm_ui 0

This is the case because ARM isn't supported for virtual machine.

Quake3 can run 3 ways, they are

vm_game 0 vm_cgame 0 vm_ui 0: run via the native dll or .so qagame*.dll/so. Fastest, but most mods aren't compiled into these.

vm_game 1 vm_cgame 1 vm_ui 1: run via the interpreter. Slow and buggy, won't work for most mods.

vm_game 2 vm_cgame 2 vm_ui 2: compile qagame.vm to native processor architecture at run time. What a lot of mods and what the default is for Quake 3 on x86 and other supported platforms.

So if I understand you correctly, an ARM back-end would be very desirable, right? Any idea of what the impact on speed the interpreted VM has?

 

[conso]

why do you talk about backend all the time?
As far as I understand, there is a compiler for ARM, but no interpreter. That shouldn't matter as most mods don't use the interpreter anyway, but compile on runtime.

 

[ldesnogu]

conso, you didn't get it

 

[WizardStan]

conso, you didn't get it

That makes two of us. Can you explain?

 

[notaz]

niiice!

would a kind soul provide the outputs from eglQueryString(EGL_EXTENSIONS) and glGetString(GL_EXTENSIONS) with the new drivers, please?

My first ever *gl program outputs:

display: 0x1
eglInitialize 1, 1.4
EGL_VENDOR: Imagination Technologies
EGL_VERSION: 1.4 build 1.4.14.2514
EGL_EXTENSIONS: EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image
  EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image
  EGL_KHR_vg_parent_image EGL_IMG_context_priority 
EGL_CLIENT_APIS: OpenGL_ES OpenVG

What do I have to init to get glGetString() return stuff?

 

[MDave]

Not if the game code has been compiled into dynamic libraries (.so files) and the following cvars are set: vm_game 0 vm_cgame 0 vm_ui 0

This is the case because ARM isn't supported for virtual machine.

Quake3 can run 3 ways, they are

vm_game 0 vm_cgame 0 vm_ui 0: run via the native dll or .so qagame*.dll/so. Fastest, but most mods aren't compiled into these.

vm_game 1 vm_cgame 1 vm_ui 1: run via the interpreter. Slow and buggy, won't work for most mods.

vm_game 2 vm_cgame 2 vm_ui 2: compile qagame.vm to native processor architecture at run time. What a lot of mods and what the default is for Quake 3 on x86 and other supported platforms.

So if I understand you correctly, an ARM back-end would be very desirable, right? Any idea of what the impact on speed the interpreted VM has?

Yes, an ARM back end would indeed be very desirable I'm not sure how much an impact interpreted mode has, I think it depends on the game in question, if it uses lots of calculations for things like physics for example. Q3Rally would be a good test there, since Quake 3 itself is pretty basic.

I've tried interpreter mode for quake 3 and a few mods, and it always seems to crash as soon as I get ingame, so I can't test it myself. Menus work ok though.

 

[Adventus]

What do I have to init to get glGetString() return stuff?

You would probably need an ogl context. Doesn't /usr/bin/gl2info print out this information?

 

[ldesnogu]

@ WizardStan, conso: sorry, I'll try to explain. For me a back-end is a program that takes some input and generates native code. In that case, it would mean translating Quake3 internal representation (qvm, for Quake virtual machine) into ARM code at runtime.

 

[WizardStan]

@ WizardStan, conso: sorry, I'll try to explain. For me a back-end is a program that takes some input and generates native code. In that case, it would mean translating Quake3 internal representation (qvm, for Quake virtual machine) into ARM code at runtime.

Ah, you want the third option so we can run any Q3 mod, correct? Your followup question about the interpreted VM threw me off, as I'm pretty sure it doesn't work properly anyway (if I understand correctly) so can't in any way be a source of slow down.