New PowerVR demos

[Ailuros]

http://www.pvrdev.com/pub/PC/eg/h/Cloth.htm

Cloth

In computer graphics, simulating cloth has always been a topic of much research. In everyday life we observe cloth behaviour without realizing the complexity of the physics involved. The model and shaders introduced in this demo attempt to simulate cloth using a simplified mass-less spring model which can be executed completely by next generation graphics hardware. The spring model is used to generate the position and normal of a cloth’s control points, which are then stored into “geometry textures†using an advanced Pixel Shader 3.0. Finally, the vertex texturing capabilities of the Vertex Shader 3.0 model allows us to render the deformed cloth using the position and normal data stored in these geometry textures.

http://www.pvrdev.com/pub/PC/eg/h/DeferredShading.htm

Deferred Shading

Traditional rendering algorithms submit geometry and immediately apply shading effects to the rasterised primitives. Complex shading effects often require multiple render passes to produce the final pixel colour, with the geometry submitted every pass. Deferred shading (a.k.a. Quad Shading) is an alternative rendering technique that submits the scene geometry only once, storing per-pixel attributes into local video memory to be used in the subsequent rendering passes. In these later passes, screen-aligned quads are rendered, and the per-pixel attributes contained in the buffer are retrieved at a 1:1 mapping ratio so that each pixel is shaded individually.

http://www.pvrdev.com/pub/PC/eg/h/Voxel.htm

Voxel

With the advent of Pixel Shader 3_0, graphics hardware has become capable of rendering hardware-accelerated voxels.

Voxel objects are stored as a three dimensional map of matter, with each voxel (or texel in a volume map) indicating something about that “lump†of matter – its colour, translucency, or “power†in the case of metaballs. In the “power†case, a threshold value is used; voxel values that are above (or below) this value are considered to be solid matter, with the rest considered to be empty space.

Typically, voxel objects are converted to polygons before rendering using the “marching cubes†algorithm, or similar. The method presented here submits a single eight-vertex cube and extracts the surface in the pixel shader; a ray is traced step by step through the volume, sampling the texture at each step, searching for matter.

 

[Joe DeFuria]

OK, um, so we have some demos that use PS/VS 3.0?

On what hardware does this run? 8)

 

[Ailuros]

Captain Obvious wrote:

Obviously on upcoming PowerVR hardware.

PS: I didn't expect anyone else to reply first to this thread LOL

 

[Rodéric]

I'm waiting for this board, that why I didn't upgraded my ATI RadeOn 8500 yet...

I hope it gets on the shelves SOON

(Within 6 months would be perfect)

 

[dan2097]

The deffered rendering with MRT demo seems to run adequatly on my r9700. It has issues with either forced af or fsaa but disabling them makes it display properly

20fps on HAL
21fps on Pure HAL

default windowed res

EDIt: cant repeat the af/fsaa graphical corruption maybe it was a one off. Frame rates drop a tad to maybe 19 as the light moves

 

[R300King!]

I get similar on the D3D Deferred Shading

HAL = 21
Pure HAL = 22

It fluxuates but it's around there. I have P4 2.53, 9700pro stock speeds.

The original demo(cloth) doesn't work..I get an error.

Are there any other of the demos on that page that will run?

 

[Kristof]

The original demo(cloth) doesn't work..I get an error.

Which error do you get ? Complaint about not having VS/PS 3.0 ?

Should work fine if you add "-Refdevice" on the command line, assuming you have the reference rasterizer available on your system (not sure if its included in the default DX distribution, might only be in the SDK DX distro).

 

[R300King!]

I only downloaded the executable only file, but here are the errors I got.

http://63.249.234.130/0pics/forum/Demo Error/Cloth Demo/error_1.jpg
http://63.249.234.130/0pics/forum/Demo Error/Cloth Demo/error_2.jpg
http://63.249.234.130/0pics/forum/Demo Error/Cloth Demo/error_3.jpg
http://63.249.234.130/0pics/forum/Demo Error/Cloth Demo/error_4.jpg

BTW I have a P4 2.53 with 9700pro..not what my signature says..need to update it.

 

[dan2097]

Should work fine if you add "-Refdevice" on the command line, assuming you have the reference rasterizer available on your system (not sure if its included in the default DX distribution, might only be in the SDK DX distro).

Reference rasterizer =sub 1fps though doesnt it I havnt got it anyway

My card is a 9700np @303/303 just for information. Does this demo basically show the advantage of deffered rendering over an IMR like the 9700

 

[Mintmaster]

Should work fine if you add "-Refdevice" on the command line, assuming you have the reference rasterizer available on your system (not sure if its included in the default DX distribution, might only be in the SDK DX distro).

Reference rasterizer =sub 1fps though doesnt it I havnt got it anyway

My card is a 9700np @303/303 just for information. Does this demo basically show the advantage of deffered rendering over an IMR like the 9700

Sort of, I guess. What it does is store all lighting data (i.e. normals) in a texture the size of the screen, and then uses this texture to light the scene afterwards. That way the lighting portion is only done for all visible pixels. So you're deferring the lighting part.

There's an article here about it:
http://www.beyond3d.com/articles/deflight/

 

[demalion]

Anyone else experimenting with the A2R10G10B10 option for the deferred lighting demo? Dims the output as makes sense when windowed, but not many gradients that I saw for evaluating what full screen differences there might be.
Maybe color/bit counting of screenshots will tell me more.

EDIT: Hmm...no full screen 10 bit color components supported (on my hardware...), that's why it looks normal in full screen. Maybe the windowed 10 bit support is scaled to the actual output by Windows or the full screen limitation is an artificial program thing, rather than it being something done by drivers like I was thinking. I'd hoped full screen would have allowed a suitable gamma table to be used.

The colors don't look distorted, that I've noticed...just dimmer.

 

[KimB]

My card is a 9700np @303/303 just for information. Does this demo basically show the advantage of deffered rendering over an IMR like the 9700

No, but a deferred renderer would probably like this approach much more than an IMR.

Deferred renderers lose efficiency with more geometry. IMR's are mostly fillrate-bound, so it may be better to send the geometry multiple times if less work has to be done by the pixel shader.

 

[Kristof]

I only downloaded the executable only file, but here are the errors I got.

http://63.249.234.130/0pics/forum/Demo Error/Cloth Demo/error_1.jpg
http://63.249.234.130/0pics/forum/Demo Error/Cloth Demo/error_2.jpg
http://63.249.234.130/0pics/forum/Demo Error/Cloth Demo/error_3.jpg
http://63.249.234.130/0pics/forum/Demo Error/Cloth Demo/error_4.jpg

BTW I have a P4 2.53 with 9700pro..not what my signature says..need to update it.

Yep, those are the default errors, first one indicates you did not specify an object file (contains all kinds of settings which influence the cloth model and the objects the cloth draped over) - The various Obj files are included in the source distribution. I put the controls in a text file because when you have only the ref rast you can't really change the settings interactively during the running of the demo. Second error tells you how to solve it (run with ref device since your hardware does not support VS/PS 3.0). Error 3 and 4 are default shell/framework errors when the app fails to init.

 

[Kristof]

Should work fine if you add "-Refdevice" on the command line, assuming you have the reference rasterizer available on your system (not sure if its included in the default DX distribution, might only be in the SDK DX distro).

Reference rasterizer =sub 1fps though doesnt it I havnt got it anyway

My card is a 9700np @303/303 just for information. Does this demo basically show the advantage of deffered rendering over an IMR like the 9700

Yep, ref rast is about 5 to 7 seconds per frame on a P4-2.0GHz IIRC.

Yes, and no... this is deferred rendering in the sence that you do an initial render pass which lays down the geometry info in a set of MRTs (position, normals anything you need to calculate the final pixel color). You then do multiple passes per light to build the final image using the info in the geometry buffers. Advantage is you don't have to resend the base geometry over and over again to update the light effect. Its an alternative to the DoomIII rendering system IIRC. Anyway once we publish the articles (currently available already in the ShaderX2 book) things should become clear.

 

[ActionNews]

Kristof i guess these demos have been tested on PowerVR Hardware 8) ?

CU ActionNews

 

[Arun]

this is deferred rendering in the sence that you do an initial render pass which lays down the geometry info in a set of MRTs (position, normals anything you need to calculate the final pixel color). You then do multiple passes per light to build the final image using the info in the geometry buffers. Advantage is you don't have to resend the base geometry over and over again to update the light effect. Its an alternative to the DoomIII rendering system IIRC. Anyway once we publish the articles (currently available already in the ShaderX2 book) things should become clear.

But, wouldn't that take a lot of video memo...
Oh, wait.

Not bad, not bad at all in fact... Should show your hardware in a pretty good light indeed! Could be pretty good for other ones, too, although probably not anywhere as interesting.


Uttar

 

[Tahir2]

With a geometry buffer is the buffer internal (i.e. on die cache) or external?

Does it save bandwidth at the expense of memory usage or save both memory usage and bandwidth or does it just allow the GPU to save on computation speed (i.e. resending the geometry = more GPU cycles spent on it)?

Sorry for the lame questions....

P.S. I am not talking directly about the new PVR GPU but the Geometry Buffer itself so if anyone gives any insight into this I am sure they won't be breaking any NDA's. *cough* *cough*

 

[Megadrive1988]

I cannot tell you how long I have been DYING to hear about the next major PowerVR chip since PowerVR Series 3 / KYRO.


Was looking forward to Series 4 (4 pipes + geometry processing) with great anticipation. hopes dashed when cancelled.


Series 5 became "the great hope" for PowerVR (no not hype!)


MBX was interesting, but really a side show.


Now I hope that Series 5 will really emerge.


I also hope that Series 6 has a future with the next generation of consoles in 2005-2006.

 

[Ailuros]

Last time I checked their official documents they are aiming to land console deals with Series5 too.

 

[KimB]

I just don't think PowerVR stands a chance of putting out a truly good GPU in the consumer sector. With their current business model, their product will always take a long time to get to market. I don't think they'll ever be able to be competitive.

That is, even if they do have a finished design, and are able to get a few chips out for review by early next year, it will take some time to set up all the necessary licesnsing deals, and subsequent production.