Skip to main content

Microsoft Silverlight

Answered Question Dynamically generate pixel shader?RSS Feed

(0)

ksleung
ksleung

Contributor

Contributor

5198 points

993 Posts

Dynamically generate pixel shader?

Hi,

Does anyone know where I can find more details or documentation about the compiled pixel shader format (.ps files)?  I am wondering if it is possible for me to dynamically generate pixel shaders by creating the .ps files directly.  I am not talking about varying the parameters of a pixel shader (like the WPF effect library).  I also cannot dynamically generate .fx files and compile them into .ps files because I want the .ps files to be dynamically generated by the Silverlight application (and I don't want server-based pixel shader compiler), and I'm willing to write in the assembly level.

I know this is a rather bizzare request and is a long-shot, but who knows, maybe I'd be surprised Stick out tongue

Krasshirsch
Krasshirsch

Participant

Participant

1029 points

295 Posts

Re: Dynamically generate pixel shader?

Generating ps files is not possible without the DX API at the moment.

A Bro must always post bail for another Bro, unless it's out of state or, like, crazy expensive.

Crazy Expensive Bail > (Years You've been Bros) * $100

Alexander Wieser
Germany

ksleung
ksleung

Contributor

Contributor

5198 points

993 Posts

Re: Dynamically generate pixel shader?

Not necessarily, since the .ps file could be very small.  At the end of the day it is just a byte stream, and I even know what the assembly instructions should be (using ildasm.exe on sample fx files).

Krasshirsch
Krasshirsch

Participant

Participant

1029 points

295 Posts

Re: Dynamically generate pixel shader?

You still need a compiler, of course you can write your own, but this will be a project of its own. There is no ready to use compiler, which works with non native code. If your interested, perhaps you'll find something within nvidas developer zone, im pretty sure you wont here. http://developer.nvidia.com/object/cg_toolkit.html

A Bro must always post bail for another Bro, unless it's out of state or, like, crazy expensive.

Crazy Expensive Bail > (Years You've been Bros) * $100

Alexander Wieser
Germany

ksleung
ksleung

Contributor

Contributor

5198 points

993 Posts

Re: Dynamically generate pixel shader?

i guess i would like to write that compiler, and it is a simple compiler.  For example, only thing it does is ((((((A op1 B) op2 C) op3 D) op4 E) op5 F) op6 G), where say op* being either +, -, *, or /.  So the question is what exactly the target byte code looks like.  I guess I can always try to reverse-engineer, but I was hoping for a more "correct' approach.  Anyway, thanks for your help.

planetmarshall
planetma...

Member

Member

60 points

20 Posts

Re: Dynamically generate pixel shader?

I thought this was an interesting problem and looked into it, but while on the face of it the DirectX DDK provides everything you need to write a compiler, Silverlight just doesn't provide the infrastructure to use generated pixel shader byte code directly. There is no equivalent to WPF's PixelShader.SetStreamSource() function.

 You can only set pixel shaders using the pack URI schema - if someone can come up with a way to load a dynamically generated byte[] array using a pack URI string, then I'll happily post some of the basic shader generation code I was working on until I discovered SetStreamSource was missing from the Silverlight API.

  Andrew.

ksleung
ksleung

Contributor

Contributor

5198 points

993 Posts

Answered Question

Re: Dynamically generate pixel shader?

Andrew,

Wow, great to hear that it can be done!  I was looking for how to do that in the last couple of days but couldn't find anything helpful.  I guess I wasn't familiar enough with DirectX to venture further.

Regardless the pack URI schema...  this is a bummer!  Hmm...  seems like there are two really ugly workarounds:

(1) bounce the byte stream to a server so that you can refer to the URI (I assume it takes any URI, not just packed ones).

(2) have a dynamically create assembly (as a byte stream) such that it contains the ps file as "content" (basically a very simple non-compressing zip file needs to be generated).  Load the assembly (I know it takes a byte stream) and now you can refer to content of the assembly.  The problem is that I don't think assemblies are garbage collectible, and so every time a new shader is created, it hogs up some memory (and I don't know how much).

Under these conditions, would it still be okay to share the code?  Even (1) per se could be useful enough.

  • Unanswered Question
  • Answered Question
  • Announcement
Microsoft Communities