RenderMan shaders in hardware

[Humus]

Saw this has gone online now on the public developer site.
http://mirror.ati.com/developer/index.html

Grab the Ashli demo from there. It's quite cool; runs RenderMan shaders on current generation hardware.

 

[Ostsol]

I wonder if this RenderMan compiler (or an improved version) will be in the next version of RenderMonkey.

 

[Mintmaster]

I think this is the demo at the ATI event that ran at 50 fps on a 9800 PRO and only 2 fps on a Quadro FX 2000.

 

[DemoCoder]

It runs some shaders in HW. They have some ways to go before you can load up a frame from Toy Story and have all the shaders work.

Nice piece of work, but let's not get excited about RM in realtime yet.

 

[croc_mak]

>>Nice piece of work, but let's not get excited about RM in realtime yet

Can you explain what you mean by RM in realtime? If you mean running ANY Renderman rib scene in real-time that's never going to happen. You can always shader that can run a BILION iterations

Actually come to think of it....No one should ever make a claim of Direct3d in realtime or Opengl in realtime for that matter.

Also, for the benefit of the less informed...The term "renderman" is very loosely used....There is the renderman shading langauge and there is the Renderman RIB interface.

This demo from ATI is just a shading language compiler.....It is NOT a Renderman renderer..This term usually applies to packages that take in a rib file as input and produce a series of rendered images as output.

 

[DeanoC]

SGI did it some years ago.... (Realtime RMSL)

Do ATI support displacement mapping? they can do it under OpenGl using 2 passes but I wouldn't be surprised if they didn't.

I never really understand why people are impressed with RenderManSL. It was great 10 years ago but its actually behind HLSL, Cg and GLSlang in many ways.

Its only support one set of UV coodinates per object, it couldn't even do a Quake 2 shader

Its the programmer's of RendermanSL and PRMan thats impressive not the language.

 

[MfA]

Those shader languages you mention are all compromised to fit existing hardware ... it would have been nice if we had a general SL after 10 years which could truly boast to be superior in every way.

It is hard to be impressed by languages which have an expiry date.

 

[Humus]

It runs some shaders in HW. They have some ways to go before you can load up a frame from Toy Story and have all the shaders work.

Nice piece of work, but let's not get excited about RM in realtime yet.

"Some", yes, even "many", and it does it well. I think it's farily exciting. Still some ways to go, but it's a large and important step.

Some interesting links from the same site:
http://mirror.ati.com/developer/gdc/AshliMayaGDC.pdf
http://www.ati.com/developer/gdc/AshliMaxGDC.pdf

 

[Humus]

I never really understand why people are impressed with RenderManSL. It was great 10 years ago but its actually behind HLSL, Cg and GLSlang in many ways.

Its only support one set of UV coodinates per object, it couldn't even do a Quake 2 shader

Its the programmer's of RendermanSL and PRMan thats impressive not the language.

The RenderMan language is significant due to it being a industry standard and there are loads of RenderMan compatible renderers, editors, graphical tools for creating these shader and a huge amount of already written shaders ready to be taken advantage of.

 

[DeanoC]

Those shader languages you mention are all compromised to fit existing hardware ... it would have been nice if we had a general SL after 10 years which could truly boast to be superior in every way.

It is hard to be impressed by languages which have an expiry date.

Actually the langauges are largely free of hardware constraints, certainly alot less then RMSL is free from Reyes constraints.

HLSL and Cg don't really have any constraints. The compiler don't yet handle everything completely but what have they left out? Array access is one feature not completly supported, but then they support textures which are superset of most arrays.

RenderMan is a good PRMan fragment shader but it offers few capabilities over the new languages. Its main advantage is the vertex and pixel unified but that is also a weakness. It never designed to cope with arbitary data modification.

HLSL et al were designed both as fragment shaders and geometic(vertex) shader.Already we are seeing the modern languages supporting patch evaluation, bone systems, light shaders etc. Don't underestimate how much more general HLSL et al are over RMSL.

In several years time, the hardware may support a unified model like RMSL. The languages won't need changing, just the input and output sementics and we would have per pixel displacement maps.

 

[nAo]

Nice indeed, but what about light and geometry shaders?
And I wonder what Nvidia is doing with the acquired ExLuna assets

ciao,
Marco

 

[DeanoC]

I never really understand why people are impressed with RenderManSL. It was great 10 years ago but its actually behind HLSL, Cg and GLSlang in many ways.

Its only support one set of UV coodinates per object, it couldn't even do a Quake 2 shader

Its the programmer's of RendermanSL and PRMan thats impressive not the language.

The RenderMan language is significant due to it being a industry standard and there are loads of RenderMan compatible renderers, editors, graphical tools for creating these shader and a huge amount of already written shaders ready to be taken advantage of.

That I agree with, it is the offline rendering standard, but lets hope it doesn't become MY industries standard.

I think the work done is wonderful, Its important to acquire business in the CGI field but apart from the obvious "Wow! Now we can run Toy Story in real-time " its nothing really different from NVIDIA parsing the Final Fantasy Movie scenes.

Maybe I'm just tired and jaded

Anyway congratulation to the authors, it certainly an achievement that the CG worlds been waiting for.

 

[MfA]

HLSL and Cg don't really have any constraints. The compiler don't yet handle everything completely but what have they left out? Array access is one feature not completly supported, but then they support textures which are superset of most arrays.

Well you can put a renderer complete with adaptive subdivision in the vertex shader, but that isnt really the kind of general I meant ... I meant more the surface shader approach versus vertex/pixel shaders you mentioned later.

RenderMan is a good PRMan fragment shader but it offers few capabilities over the new languages. Its main advantage is the vertex and pixel unified but that is also a weakness. It never designed to cope with arbitary data modification.

The language cant help in this respect, it is up to the rendering engine to cope with data modification. It knows how large polygons are after modification, it can be adaptive if you want it to.

HLSL et al were designed both as fragment shaders and geometic(vertex) shader.Already we are seeing the modern languages supporting patch evaluation, bone systems, light shaders etc. Don't underestimate how much more general HLSL et al are over RMSL.

I dont believe we should seek to do general purpose processing in the shader language ... I dont even believe animation belongs in the shading language really. But you are right, they are more general purpose languages if you want to use them as such.

Marco

PS. I think it is easier to render a scene described with Renderman with a raytracer than one "described" with rendering-engine-in-a-vertex-shader type of approaches ... so I still say they are more dependent on the underlying hardware.

 

[LeStoffer]

Cool stuff me thinks.

Minor annoyance: The AshliViewer doesn't fit into 1024x768.

 

[RussSchultz]

Some of the renders didn't show up for me on my 9500. (Fur didn't look very convincing, either).

 

[MuFu]

In several years time, the hardware may support a unified model...

I wouldn't say "several years".

MuFu.

 

[Goragoth]

I'm going to have to have a play around with this. Realtime accurate feedback on materials and the like is really going to help CGI a lot.