Tile based deferred rendering consoles

woooooowww! that's cool, dude.
That makes me think if the whole universe is tile based deferred rendered.
If so, that would nullify the assumption that the only console that has used tile based deferred rendering is Dreamcast.

Anyway, I'm happy that jvd's the gay, not you. You don't even look gay, whereas jvd's sooo obvious gay bear.

Do you think I'd have a chance with jvd? I kinda like bears ;)
Oh, I forgot, how could you know as you're only acting gay (not very convincingly, might I add)
 
rabidrabbit said:
woooooowww! that's cool, dude.
That makes me think if the whole universe is tile based deferred rendered.
If so, that would nullify the assumption that the only console that has used tile based deferred rendering is Dreamcast.

Anyway, I'm happy that jvd's the gay, not you. You don't even look gay, whereas jvd's sooo obvious gay bear.

Do you think I'd have a chance with jvd? I kinda like bears ;)
Oh, I forgot, how could you know as you're only acting gay (not very convincingly, might I add)

Not very convincingly? Hey, i LOVE brittany! And Madonna! And i wave my hands even while typing! Hows that? :LOL:
 
This thread has been rendered off topic, so I'm deffering my post until I've finished tiling my bathroom.
 
Lazy8s said:
Can anyone who attended PowerVR's MBX demonstrations at this year's GDC specify the approximate performance that was being represented by the ARM Versatile development platform demos?
That particular ARM dev system is not a full-speed system, but even so it's no slouch. A colleague and I did the curved surface work on it and were quite pleased with the results.

Trying to clarify a topic on mobile comparisons over at http://www.ga-forum.com/showthread.php?t=3174&page=3

Naturally you can take my comments with a grain of the usual saline substance, but that same colleague attended GDC and was underwhelmed by the PSP presentation.

Also noticed on that thread:
Lazy, unless you can affirm that the Rensas chip can push those and better ( a single teapot in front of a flat background is not what you should consider as peak of PSP graphical quality ) graphics then the point is moot still.
That demo was just to show off continuous LOD for curved surfaces. It ran on the ARM system and had 'a bit' of performance headroom :)
 
Jaws said:
This thread has been rendered off topic, so I'm deffering my post until I've finished tiling my bathroom.
I hated the bit where I had to do 'clipping' around the sink and toilet. Absolute nightmare.
 
Simon said:
Naturally you can take my comments with a grain of the usual saline substance, but that same colleague attended GDC and was underwhelmed by the PSPpresentation.
Granted however, comparing a sketchy presentation of incomplete hw spec to another hw with full knowledge of its complete spec, it's a bit hard to walk away impressed.
And no matter how fair a person you are, it only gets harder yet, to be impressed with former if you also have actual work involvement with the latter ;)

Personally I have plenty of doubts about market potential of PSP, but from hardware perspective, it's probably my favourite of the newgen stuff at the moment. Granted, I also had a soft spot for GBA at one point. :p
 
Simon F said:
That demo was just to show off continuous LOD for curved surfaces. It ran on the ARM system and had 'a bit' of performance headroom :)

Simon, I cannot help it if an ARM9 CPU + PVR MBX with VGP blows out the PSP out of the water performance wise :p.

Seriously, I will be the first to admit that if you can support different LODs for neighbouring patches without cracks then your solution has an advantage there.

There are probably Sony guys who saw the MBX presentation and are still more impressed by their own solution more than the MBX.

Hopefully we will see an ARM set-up with ARM9 CPU and ARM9 VFPU + PVR MBX with VGP.

As I said in that thread, PSP is no slouch performance wise: improved rendering core ( more features than the GS and more efficient ), fast T&L unit on the GPU, 32 MB of main RAM, 2.6 GFLOPS VFPU on the main CPU, 664 MPixels/s of fill-rate attached to fast e-DRAM ( 256 bits bus for 4 pixel pipelines ).

I am pretty excited about the Renesas solution: the CPU they have used is an SH-4 at 400 MHz, 2x faster than what the Dreamcast used.




EDIT: I wrote 512 bits bus instead of 256 bits.

The main CPU is attached to a 128 bits bus, while the GPU is attached to a 256 bits bus.
 
Panajev2001a said:
Simon F said:
That demo was just to show off continuous LOD for curved surfaces. It ran on the ARM system and had 'a bit' of performance headroom :)

Simon, I cannot help it if an ARM9 CPU + PVR MBX with VGP blows out the PSP out of the water performance wise :p.
I wouldn't know if that was the case or not. The PSP could well have much more power but then I suspect the die size and (electrical) power usage is probably more than proportionally higher. The feedback I got from my colleague was to do with some of the programming model decisions which seemed a little 'odd'.
Seriously, I will be the first to admit that if you can support different LODs for neighbouring patches without cracks then your solution has an advantage there.
When I get a chance, I hope to port the technique to another piece of HW which has even better features for this sort of thing.

Hopefully we will see an ARM set-up with ARM9 CPU and ARM9 VFPU + PVR MBX with VGP.
I think that was what my colleague took to GDC.
As I said in that thread, PSP is no slouch performance wise: improved rendering core ( more features than the GS and more efficient ), fast T&L unit on the GPU, 32 MB of main RAM, 2.6 GFLOPS VFPU on the main CPU, 664 MPixels/s of fill-rate attached to fast e-DRAM ( 512 bits bus for 4 pixel pipelines ).
166Mhz * 4 pixel pipes? That's quite substantial for a portable. Any idea what "fast T&L" implies in terms of performance?

I am pretty excited about the Renesas solution: the CPU they have used is an SH-4 at 400 MHz, 2x faster than what the Dreamcast used.
Indeed. For an SOC, it's a bit of a beast.
 
Simon F said:
When I get a chance, I hope to port the technique to another piece of HW which has even better features for this sort of thing.

Shhh, you cannot tease too much... ever heard of "blue transistors" ? ;).

As I said in that thread, PSP is no slouch performance wise: improved rendering core ( more features than the GS and more efficient ), fast T&L unit on the GPU, 32 MB of main RAM, 2.6 GFLOPS VFPU on the main CPU, 664 MPixels/s of fill-rate attached to fast e-DRAM ( 512 bits bus for 4 pixel pipelines ).
166Mhz * 4 pixel pipes? That's quite substantial for a portable. Any idea what "fast T&L" implies in terms of performance?

Fast ? Say 33 MVertices/s as T&L peak for the PSP 's GPU Hardwired T&L unit.

Then you have to add the VFPU Sony attached to the R4000i CPU which packs 2.6 GFLOPS.

About the pixel-pipelines, Sony announced, in their own presentation papers, the fill-rate and the clock-speed for the GPU rendering core ( 664 MPixels/s and 166 MHz ) together with the e-DRAM bus speed and width ( VRAM uses a 256 bits bus and peaks at 5.2 GB/s ): 664 MPixels/s / 166 MHz = 4 :).

So, they did not specify 4 pixel pipelines directly, but do you agree with me that the conclusion I made was justified :) ?

Indeed. For an SOC, it's a bit of a beast.

Yes, I do agree, it is very impressive.

Let's hope that software makers will push that solution accordingly: if only SEGA had been healty and independent, this could have been their portable.
 
Panajev2001a said:
Simon F said:
When I get a chance, I hope to port the technique to another piece of HW which has even better features for this sort of thing.

Shhh, you cannot tease too much... ever heard of "blue transistors" ? ;).
Yooouch.
166Mhz * 4 pixel pipes? That's quite substantial for a portable. Any idea what "fast T&L" implies in terms of performance?
Fast ? Say 33 MVertices/s as T&L peak for the PSP 's GPU Hardwired T&L unit.
So again assuming 166Mhz clock that's 5 cycles per vert which probably corresponds to 4 DPs for the transform and 1 for the lighting. That sounds about "par for the course".
About the pixel-pipelines, Sony announced, in their own presentation papers, the fill-rate and the clock-speed for the GPU rendering core ( 664 MPixels/s and 166 MHz ) together with the e-DRAM bus speed and width ( VRAM uses a 256 bits bus and peaks at 5.2 GB/s ): 664 MPixels/s / 166 MHz = 4 :).

So, they did not specify 4 pixel pipelines directly, but do you agree with me that the conclusion I made was justified :) ?
Seems perfectly reasonable to me.
 
So again assuming 166Mhz clock that's 5 cycles per vert which probably corresponds to 4 DPs for the transform and 1 for the lighting. That sounds about "par for the course".

Somehow, I see a smirk on your face ( like "bah that ain't fast" ) when you say that :p.
 
rabidrabbit said:
Has there been any other consoles other than DC,
or graphics cards other than PowerVR cards, that have used tile based deferred rendering?
I'm pretty sure DC is the only console, that has had tile based rendering, but what about PCs or workstations?

Gigapixel had some sort of prototype that did, and microsoft may have.

Dreamcast must be the only console with tbdr though, as its the only one whos texel rate gets higher as there are more texture layers.
 
Panajev2001a said:
So again assuming 166Mhz clock that's 5 cycles per vert which probably corresponds to 4 DPs for the transform and 1 for the lighting. That sounds about "par for the course".

Somehow, I see a smirk on your face ( like "bah that ain't fast" ) when you say that :p.
No, I was just thinking that sounds like a sensible rate.
 
Back
Top