Pandora Sgx Driver Benchmarks


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
 
paddy said:
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.
 
Last edited by a moderator:
paddy said:
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.
 
Last edited by a moderator:
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.
 
niiice!

would a kind soul provide the outputs from eglQueryString(EGL_EXTENSIONS) and glGetString(GL_EXTENSIONS) with the new drivers, please?
 
darkblu said:
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.
 
Last edited by a moderator:
Laurent said:
I wonder what the impact on Q3 speed the interpreted VM has...

Could you clarify what you're referring to?
 
Last edited by a moderator:
Exophase said:
Laurent said:
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.
 
Last edited by a moderator:
Laurent said:
Exophase said:
Laurent said:
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.
 
Last edited by a moderator:
MDave said:
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?
 
Last edited by a moderator:
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.
 
darkblu said:
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:
Code:
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?
 
Last edited by a moderator:
Laurent said:
MDave said:
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.
 
Last edited by a moderator:
@ 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.
 
Laurent said:
@ 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.
 
Last edited by a moderator:
Back
Top