3d Demos

[meganab]

Will Quake4/Doom3 run with maximum graphics settings (on pandora of course)?

And someone FIX THESE DAMN FORUM BUGS!!!

 

[PhenXDesign]

As they are closed source, They won't run at all. It is made for x86, not ARM, and even if it was emulated with Qemu, it wouldn't run.

 

[meganab]

But when the engine goes open source they can be ported.

Then the guys who own the games could just unpack the data (graphics, sounds, levels) into the engine and play.

 

[PhenXDesign]

But when the engine goes open source they can be ported.

Then the guys who own the games could just unpack the data (graphics, sounds, levels) into the engine and play.

When it will go open source, there will be the Pandora III.

 

[Xmas]

True and not true at the same time. ;]
SGX registers are scalar

True and not true at the same time.

QUOTE
so most of the time shader that calculates 3 channels takes 3x more clocks that shader that calculates only 1 channel.

It doesn't, because a) see above, and \b) the majority of calculations in complex fragment shaders do not operate on colours. Not to mention luminance may actually depend on chrominance.

While your suggestion might save a bit on the fragment side it doubles the vertex processing requirements and the draw call/state overhead.

Also, and more importantly, while colour subsampling is a clever concept for compressing images it's not well suited for 3D rendering. In the former case you start out with several colour samples which can be averaged to a single chrominance value that applies to several pixels. Your idea would only produce a single chrominance sample per block to begin with. It would lead to substantial aliasing/colour flickering in areas with dense geometry.

 

[Karel Jansens]

I CAN SEE DOOM 3 IN PANDORA!!! :blink:

Yes, and I can see dead people. But we don´t shout about it.

 

[Pickle]

Heres a little leak to those following this thread. Ive created some versions of quake 1 for pandora with the wrapper, hopefully we will see some positive results very soon. I dont have the hw yet but DJwillis is testing it for me.
Once q1 is gold, then I will start looking at q2, and so on until q3.

 

[Yod4z]

Good to know Pickle. Thanks for your hard work on GL ES support on Q engine

 

[Trip]

Good to know Pickle. Thanks for your hard work on GL ES support on Q engine

Ditto from me too

 

[MDave]

I'm wondering what the advantages and disadvantages are with going with using a wrapper for opengl, for the quake ports?

 

[Svartalf]

I'm wondering what the advantages and disadvantages are with going with using a wrapper for opengl, for the quake ports?

Speed of porting as an advantage.

Performance and the potential complexity of having to maintain enough of the state machine to do it "right" as major disadvantages. In order to really, honestly do it as a wrapper, you're re-inventing goodly portions of OpenGL on top of ES, using ES as a hardware acceleration layer.

You're better off waiting a bit for the port. Trust me on that one.

 

[maciek_urbanski]

QUOTE
so most of the time shader that calculates 3 channels takes 3x more clocks that shader that calculates only 1 channel.

It doesn't, because a) see above, and \b) the majority of calculations in complex fragment shaders do not operate on colours. Not to mention luminance may actually depend on chrominance.

Yup, I agree, that it's by no way a "magic bullet", and you cannot just re-compile given shader to work on YUV colorspace and be significantly faster...
But if you design your shaders from grounds up to work in YUV you will process less data.
And yes - it has it's own set of disadvantages - some cases when luma and chroma are interdependent being on of them.

While your suggestion might save a bit on the fragment side it doubles the vertex processing requirements and the draw call/state overhead.

My secret plan was to try to issue one bin (basically rect on screen with list of already vertex-processed data) twice. During luma shading processor would get it with one set of shaders then next pass with chroma set of shaders would fire. This idea is currently at "wishful thinking" stage - because I`d have to decipher packed format of bin data produced by tile accelerator (not to mention joining 16 bins into one to the same-size on-chip render target during chroma rndering)...
Anyway - I was suggesting to do vertex processing on NEON, and store in format produce by tile accelerator.

Also, and more importantly, while colour subsampling is a clever concept for compressing images it's not well suited for 3D rendering. In the former case you start out with several colour samples which can be averaged to a single chrominance value that applies to several pixels. Your idea would only produce a single chrominance sample per block to begin with. It would lead to substantial aliasing/colour flickering in areas with dense geometry.

Yes it might, but I hope that this "anti-aliasing for free" will work as a pre-filter that will limit aliasing/color bleed when up-sized with joint bilateral filter. But like I said - it's by no means a magic bullet.

If you`re interested in some preliminary results (I've basically re-sized screenshots of some games [Half-Life II, Diablo III, Civilization, etc...] sub-sampled them and up-sized luma) - PM me.

 

[RavenX]

Will Quake4/Doom3 run with maximum graphics settings (on pandora of course)?

What you might as well be asking is will it run Duke Nukem Forever?

 

[Pickle]

I'm wondering what the advantages and disadvantages are with going with using a wrapper for opengl, for the quake ports?

Speed of porting as an advantage.

Performance and the potential complexity of having to maintain enough of the state machine to do it "right" as major disadvantages. In order to really, honestly do it as a wrapper, you're re-inventing goodly portions of OpenGL on top of ES, using ES as a hardware acceleration layer.

You're better off waiting a bit for the port. Trust me on that one.


well the wrapper works for quake engines on nokia phones, it may not be a full opengl wrapper just enough to do the job. im also not holding my breath on someone doing a native port anytime soon.
If we want accelerated quake engines the wrapper is the quickest solution and it doesnt hurt to try it.

 

[Svartalf]

well the wrapper works for quake engines on nokia phones, it may not be a full opengl wrapper just enough to do the job. im also not holding my breath on someone doing a native port anytime soon.
If we want accelerated quake engines the wrapper is the quickest solution and it doesnt hurt to try it.

The truth of the matter is that a port's been done for ES at one point and it's of minimal effort to revive it. The truth of the matter is that the bulk of the code is already doing fastpath operations in the case of iD games (They got the ideas for OpenGL ES 1.1 from what they did in that game engine and others...); so cleaning up the renderer isn't as big a deal as one'd think. If my plate wasn't already quite overflowing on things, I'd be saying I'd do it. That's not diminishing what you're doing, mind- but it's not as hard as one'd think to get it mostly there by looking at the ES spec and cleaning house on the codebase where there's deprecated interfaces (If it's not in ES 1.1 or in ES 2.0, you might want to think about what you're doing...it's oftentimes the least efficient thing you could be doing... ).

 

[Xmas]

Yup, I agree, that it's by no way a "magic bullet", and you cannot just re-compile given shader to work on YUV colorspace and be significantly faster...
But if you design your shaders from grounds up to work in YUV you will process less data.

The only thing that changes when you want to produce YUV output is the colour data, so I'm not sure what you mean here. As I said, most calculations in complex fragment shaders aren't even affected by the choice of colour space.