Welcome, Guest
Username Password: Remember me
Anything that doesn't fit into any other category.

TOPIC: Compiling Pixel Shaders?

Re: Compiling Pixel Shaders? 2 years ago #158599

  • hugly
  • OFFLINE
  • Platinum Boarder
  • Posts: 20864
  • 2 years ago
Thanks again.

Looks nice. Shouldn't need rocket scientists to implement? Would make cross platform (and cross version) coding for effect developers much easier, I suspect.

On the other hand, how much spare time is left to support the volunteers?
It's better to travel well than to arrive...

Re: Compiling Pixel Shaders? 2 years ago #158742

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 3430
  • 2 years ago
jwrl wrote:
Actually, that fix doesn't work. I've just tested it. I even tried replacing the sincos() function with this:

xy = float2 (sin (angle), cos (angle));

That also crashes when compiled as ps_3_0, and not as the default ps_2_b. There's obviously something else at play here.


I guess a ps_3_0 compiler bug in connection with loops.

What works is to replace the 6 loop passes with 6 macro calls:
int i = 0;

   // MACRO
   #define LOOP01MACRO\
      {\
      sincos ((i * ANGLE), xy.x, xy.y);\
      xy *= radius;\
      retval += tex2D (blurSampler, uv + xy);\
      retval += tex2D (blurSampler, uv - xy);\
      xy.y = -xy.y;\
      retval += tex2D (blurSampler, uv + xy);\
      retval += tex2D (blurSampler, uv - xy);\
      xy += xy;\
      retval += tex2D (blurSampler, uv + xy);\
      retval += tex2D (blurSampler, uv - xy);\
      xy.y = -xy.y;\
      retval += tex2D (blurSampler, uv + xy);\
      retval += tex2D (blurSampler, uv - xy);\
      i ++;\
      }


      LOOP01MACRO;
      LOOP01MACRO;
      LOOP01MACRO;
      LOOP01MACRO;
      LOOP01MACRO;
      LOOP01MACRO;

Admittedly, not as elegant as a for loop.

This attachment is hidden for guests. Please log in or register to see it.
Mainly automatically translated
--------------------------------------------
Windows 10, 64 Bit
Intel i5-4440 (3,1 GHz) ; Intel HD Graphics 4600
Last Edit: 2 years ago by schrauber.

Re: Compiling Pixel Shaders? 2 years ago #158764

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 11407
  • 2 years ago
Yep, I did something similar, but with in-line code. What I find extremely puzzling is that a very similar loop in the same effect in the border generation pass. That doesn't fail.

However I'm not very inclined to "fix" a program that works as designed in its intended environment. Unless I can identify where the ps_3_0 problem lies and come up with a fix that is better for the effect I'm going to leave it as is.

At the moment I've gone back to my reference files on Cg and D3D to see if I can track down the discrepancy, or if it's a known bug in the library. If it's a known bug I will fix it. There's always the possibility that at some stage Lightworks will default to using ps_3_0 in any case, so it's best to be prepared.

[EDIT] For what it's worth, I even discarded sincos() and implemented the code with separate sin() and cos() functions. That fails too, and I can't see why.
Last Edit: 2 years ago by jwrl.

Re: Compiling Pixel Shaders? 1 year, 11 months ago #161848

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 3430
  • 1 year, 11 months ago
To get back to the question from the opening post on page 1:

hugly wrote:
I'm wondering why pixel shaders of all effects are compiled each time Lightworks is started.

Does anybody know why this is necessary, or if there are settings to avoid it?


I do not know, but have a guess that the actual shader code is only compiled into RAM (GPU RAM or CPU RAM?).
When importing a "... fxt" file is created, but this seems to contain only effects settings, name, category, etc. (if it was created from an .fx file).

If I make changes only in the actual pixel shader code, then I do not need to re-instal the effect, but only restart Lightworks for the changes to take effect (even for effects already used in timelines). If this is not desired, then the modified effect should be saved under a different file name and insatliert.
Changes to the parameters (sliders, etc.) always require re-insatlation of the effect.
Mainly automatically translated
--------------------------------------------
Windows 10, 64 Bit
Intel i5-4440 (3,1 GHz) ; Intel HD Graphics 4600
Last Edit: 1 year, 11 months ago by schrauber.

Re: Compiling Pixel Shaders? 1 month ago #204835

  • hugly
  • OFFLINE
  • Platinum Boarder
  • Posts: 20864
  • 1 month ago
Great White,

Does anything stand against this declaration to get rid of the compiler warnings, if errors are present in effects code:

#ifdef WINDOWS
   #undef PROFILE
   #define PROFILE  ps_3_0
#endif


Edit: Just to clarify, the warnings which are created by this declaration if error are present:
#ifdef WINDOWS
   #define PROFILE  ps_3_0
#endif
It's better to travel well than to arrive...
Last Edit: 1 month ago by hugly.

Re: Compiling Pixel Shaders? 1 month ago #204856

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 11407
  • 1 month ago
I have answered this based on my memory of a post by one of the developers (I think Great White) way back. It's your transparency thread. A warning is usually just that - an alert that you may have done something that you didn't intend.
Time to create page: 0.26 seconds
Scroll To Top