Curious OpenGL performance.......

[Goku7]

Ok, whenever I've tried using Pete's OpenGL plugin on my Voodoo3 (just for the heck of it), I've noticed it's really slow in comparison to his D3D plugin and Lewpy's Glide. I'm talking like framerates of less than 20 here! Oh, yeah, this is using ePSXe 1.5.2 with ePSxe Executor (whatever's the current version of that.)

Now, judging from that, you'd think that my Voodoo3 isn't as adept at running in OpenGL than in the other API's, right? Here's where things start getting odd. Normal PC games, like Return to Castle Wolfenstien and Star Trek Voyager: Elite Force, with are OpenGL only, run at practically full speed with all the texture settings maxed out at 800x600. All of these tests were done on my 1.5Ghz P4 with 256mb of DDR-RAM.

So, my question is, why is it that OpenGL is so slow when doing PSX emulation, as opposed to the excellent performance I'm getting with normal PC OpenGL games?

[Phoenix Flame]

I dunno really. From previous experience Voodoo's tended to be a little narky when it comes to OpenGL apps, in that they either performed brilliantly or horribly. Also, and correct me if I'm wrong, but those games you listed above all use tweaked versions of the Quake 3 engine, which I think is 3DFX optimized.

[Prafull]

Opengl plugins for epsxe are highly optimized to be used with native opengl supporting cards while most of the pc games arent.For example my 810 runs quake 3 fine but still has problems with pete's opengl.

Anyway with a voodoo lewpy's glide plugins should be the first preference while d3d plugins the second one.

[Goku7]

Originally posted by prafull
Anyway with a voodoo lewpy's glide plugins should be the first preference while d3d plugins the second one.

I knew that. I was just interested in why there was such a discrepency between the performance in PC and emulated games using OpenGL.

[Pete Bernert]

harhar... I could tell you a few stories about discussions between me and a 3dfx OpenGL driver coder... something like that:

Pete: why is packed pixel 4-4-4-4 texture uploading so slow in OGL on 3DFX cards? That format should be nicely supported by your hardware (and your driver is reporting by ogl extension that it should work fine)?

Driver Guy: oh, well, we convert all the texture data in float values first, and convert that down to the asked texture format.

Pete: You convert already nice packed data??? Doesn't sound like a good idea for getting speed to me... and speed is one of the most important reasons for packed texture data...

Driver Guy: Simply upload all your texture data at the beginning of the game level, then the user will have no speed issues

Pete: uploading at level start... harhar... great idea with psx emulation...

[OmniDistortion]

actually I would think it is a good idea considering the fact that the PSX hardware was already pretty much forced to do so...right? It's because of the cache limitation.... or should that be all the more reason why it should reload all the cache? I think this is beyond me...

[E}I{]

LOL Pete, thats cool But i personally don't trust that someone can be lazy or stupud enough to convert pixels into float values
OmniDistortion. PSX games are no PC games. they are desighned to use ****ty PSX hardware to its limit. And ways they are using to reach that limit are quite hard even for latest PC 3D accelerators whose drivers are desighned by lazy programmers for even more lazy programmers. They have bugs, they are slow, they are.. well, I think you got my idea. You know on PC there is always Microsoft standing between you and your videocard.

[Cyberman]

Originally posted by OmniDistortion
actually I would think it is a good idea considering the fact that the PSX hardware was already pretty much forced to do so...right? It's because of the cache limitation.... or should that be all the more reason why it should reload all the cache? I think this is beyond me...

Well it's rather simple to be honest.. you don't control the texture loading in a GPU for an emu the PSX game does therefore it can happen at anytime. And lucky you it does!

Cyb

[Goku7]

So, Pete, would selecting a texture format different than 4-4-4-4 give me any speed increases? Theoretically speaking here.

And like I said, I'm only trying out the OpenGL plugin just for the heck of it, 'cause I've got nothing else to do, and I just got a relatively newer driver for the card, so I'm giving it a stress test, in a sense.

[Cyberman]

Originally posted by Pete Bernert
harhar... I could tell you a few stories about discussions between me and a 3dfx OpenGL driver coder... something like that:

Pete: why is packed pixel 4-4-4-4 texture uploading so slow in OGL on 3DFX cards? That format should be nicely supported by your hardware (and your driver is reporting by ogl extension that it should work fine)?

Driver Guy: oh, well, we convert all the texture data in float values first, and convert that down to the asked texture format.

Pete: You convert already nice packed data??? Doesn't sound like a good idea for getting speed to me... and speed is one of the most important reasons for packed texture data...

Driver Guy: Simply upload all your texture data at the beginning of the game level, then the user will have no speed issues

Pete: uploading at level start... harhar... great idea with psx emulation...

Where there any Mesa GL based OGL drivers for the Voodoo? I sware there were.. but I haven't found anything. I know one would need the 3dfx 'kit' to do it. Does the miniGL essentially translate OGL into GLIDE commands and pass them on?

Cyb

[Pete Bernert]

Originally posted by E}I{
But i personally don't trust that someone can be lazy or stupud enough to convert pixels into float values

Ehe, well, that's what he told me. In OpenGL the color/alpha components are defined to be in the ranges between 0.0 and 1.0, though.

Originally posted by Goku7
So, Pete, would selecting a texture format different than 4-4-4-4 give me any speed increases?

Yeah, in my 3dfx OGL experience (two or three years ago, I have to admit) the texture type "don't care" was much faster (that's telling the card to use whatever RGBA texture format it does want to use).

Originally posted by Cyberman
Where there any Mesa GL based OGL drivers for the Voodoo? I sware there were.. but I haven't found anything. I know one would need the 3dfx 'kit' to do it. Does the miniGL essentially translate OGL into GLIDE commands and pass
them on?

Well, the Linux 3dfx Mesa drivers were based on the Glide libraries of Daryll Strauss (and that ones worked really great in Linux on 3dfx cards... much better than the old (pre-detonator) nVidia Linux Mesa libs, which were _full_ of bugs... ehehe, that reminds me of a mail I've got from Daryll after I've complained about the nV Mesa libs: he told me simply to leave the dark gfx card side (nVidia), if I want to have good 3D gfx in Linux... luckily for me a short while after nV released their Detonator based libs, which are rocking as well )

And the 3dfx miniGL is just a sub-set of OpenGL, only designed and optimized for the Quake engine (and therefore not really usable with other OpenGL apps/games).

[Goku7]

Hey, speaking of texture formats, would using any sort of texture compression give any speed increases in PSX emulation?

Obviously, the compression techniques that cards use when the textures are pre-compressed wouldn't apply here, but I'm talking about compression that gfx cards can do internally with normal textures.

[E}I{]

Well, of course you can use any sort of compression if you feel that your PSX emu works too fast or looks too good despite all efforts made by driver programmers.

[Goku7]

I'm betting that that was sarcasm.......

[E}I{]

And really, why you need to compress cached textures if original PSX video memory was only 1 meg? In worsest for Pete's plugin case(w/o 2xSAI) you will need something like 8 Mb of texture memory. For old palettized versions and for some other plugins you need no more than 2-4 megs.(Hope I right here,Pete) And you prolly have that. I've already seen slowdown to 0.2 FPS when FF9 character turns another 10 degrees caused by slow upload speed. If you've seen this thread you could understand already that main problem in emulating PSX GPU on modern cards is slow upload speed caused by stupid texture conversion/compression. Why ask again? Imo good 3D card should have 8 Mb of fast memory for texture caching, really working AGP texturing and hardware color conversion for all major texture formats(well and some other things i not going to list here). Not monster with 64 Mb of slow memory. I even suppose that texture uploading is made slow by intention, to make game programmers avoid texture swapping and as a result make gamers buy new videocard to increase texture quality.

[Goku7]

I was thinking more along the lines of it having to decrease the time in which the game would be "stalling" while its waiting to retrieve info from the CD. Wait a minute....that's flawed logic. The only way it would decrease load times from CD is if they were pre-compressed.

Anyway, another thing it _may_ help on is on any PSX games that have LOTS of textures.

And as for the amount of VRAM I've got, its a mere 16mb of SDRAM.

[E}I{]

If PSX games use MANY textures, they do MANY uploads, because 1 meg (really almost half of it occupied by image you see on your screen) cann't hold MANY textures at once. And no matter how much videomemory your card have, it will be updated frequently. Speed of updates, not memory size will limit emu speed. And reasons for this slowness were already discussed. Oh. Hope that will be enough.

[Goku7]

Yeah, I get it now. Like I said, I was already trying to rationalize some flawed logic.

[Pete Bernert]

E}I{, I am sorry, but 8 MB will be often too less for my kind of texture caching... 32 MB to 64 MB will be optimal. Why? Easy: because of the 4/8bit pal psx textures. Many games like Spyro are reusing the same texture area with lotta different color-lookup tables. To upload that texture part each time the CLUT is changing would give a lotta slowdowns... so I have to cache the same texture part multiple times... and, for example, a single texture part of 64x64 texel, reused a 100 times with different cluts, can easily need 1-2 MByte vram on the pc gfx card... and that's just one texture area...

[E}I{]

Well, IMO if texture uploading could have more or less normal speed and your plugin uploaded only that is actually needed, then you could allow realtime uploading of all these textures w/o slowdowns. Really copying 0.5-1 Meg of data each frame is not much, if everything else is done by hardware and this 1 meg is not undergoing super smart texture conversion (well, in my plugin it takes only 10-20 clocks per pixel depending on format and when not all data in CPU cache)