| Computers Forum Index » Computer - Graphics - API (Opengl) » Programmatically get shader assembly ?... |
|
Page 1 of 1 |
|
| Author |
Message |
| Skybuck Flying... |
 Posted: Thu Nov 05, 2009 1:36 pm |
|
|
|
Guest
|
Hello,
I would like to know how/what the assembly looks like which will be
generated by a cg compiler or gl sl compiler.
This is to give me an idea of the efficiency of written shaders and what
it's doing.
I wonder if there is programmatically a way to retrieve the assembly via
dll's/api calls ?
The only possibility I have found so far is using the cgc compiler and
specify -entry <id> -o assembly.txt <shader.cg>
I also wonder what to do in the case of opengl sl ? Which I might look into
in the future ?
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| Wolfgang Draxinger... |
| Posted: Fri Nov 06, 2009 3:00 pm |
|
|
|
Guest
|
Skybuck Flying wrote:
Quote: Hello,
I would like to know how/what the assembly looks like which will be
generated by a cg compiler or gl sl compiler.
The GLSL compiler in NVidia's drivers are actually also performing a
conversion to assembly. The shader source code can be retrieved from OpenGL
(I'm not going to tell you how, because, if you understood how the OpenGL
API has been designed you mind would start looking for a function starting
with glGet...).
Quote: This is to give me an idea of the efficiency of written shaders and what
it's doing.
It won't. The assembly used in the OpenGL API is just an abstract
representation of the program which is transformed further into the real
machine code. And the latter one is totally depending on the used GPU and
without exact knowledge of that's innver workings you won't give you the
slightest idea, what's performant and what's not.
Also a GPU-specific GLSL compiler may be able to create more performant GPU-
machine code directly, as if it took the bypass of a intermediate ARB-like
assembler. If you want to optimize, don't look at the assembly level.
Instead profile your code and try optimizing the algorithms. This statement
holds for both the GPUs ans CPUs. Microoptimization won't gain you much.
Quote: I also wonder what to do in the case of opengl sl ? Which I might look
into in the future ?
Definitely GLSL. Cg is a dead track. (Just it is NVidia's CUDA compared to
OpenCL).
Wolfgang |
|
|
| Back to top |
|
|
|
| Dave Eberly... |
| Posted: Sun Nov 08, 2009 4:29 am |
|
|
|
Guest
|
"Wolfgang Draxinger" <wdraxinger at (no spam) darkstargames.de> wrote in message
news:4867214.946Emhk5qW at (no spam) narfi.yggdrasil.draxit.de...
Quote: Definitely GLSL. Cg is a dead track. (Just it is NVidia's CUDA compared to
OpenCL).
Would you please explain your statement about Cg? Do you mean the
Cg compiler or the Cg runtime (or both)? Why do you believe it is a
"dead track".
Did you mean to say "Just as it is with NVidia's CUDA ..."? Do you
believe that CUDA is a "dead track"? If so, why?
Thanks for any clarification.
--
Dave Eberly
http://www.geometrictools.com |
|
|
| Back to top |
|
|
|
| Wolfgang Draxinger... |
| Posted: Sun Nov 08, 2009 10:06 pm |
|
|
|
Guest
|
Dave Eberly wrote:
Quote: Would you please explain your statement about Cg? Do you mean the
Cg compiler or the Cg runtime (or both)? Why do you believe it is a
"dead track".
Cg has become a wrapper around a wrapper around a wrapper. If one uses Cg
together with a non-NVidia backend using Shader Model 4 functionality, Cg
will compile to GLSL, where the GLSL may be not as concise as the original
Cg. This might flatten the optimizer of the GLSL compiler. This is a problem
of every compiler: One can write even the simplest functions in such
complicated ways, that the optimizer just doesn't get it. The LLVM people
are doing some research on that ATM:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-July/024098.html
And I think I'm not wrong, stating the the GLSL compiler optimizers not yet
reached the level of sophistication other compilers already have.
IMHO OpenGL (and OpenCL, too) should add for some language independet, low
level program representation (some kind of AST), that allows for easy and
yet good translation into machine code.
Quote: Did you mean to say "Just as it is with NVidia's CUDA ..."? Do you
believe that CUDA is a "dead track"? If so, why?
CUDA locks you into NVidia systems, whereas OpenCL is platform neutral. A
conforming OpenCL program can be compiled to a large variety of platforms.
If you're a scientist, developing a parallel numerical application you can
do this on your desktop workstation, using either the GPU, a Cell-CPU board
plugged into PCI-E. Then you can easily migrate to the institute's cluster
of PS3, and finally might even get some processing time on the next
supercomputer.
CUDA just can't scale to such dimensions, as it's developed and runs only on
hardware by a single vendor.
Remeber what happened to 3Dfx. Their API (Glide), was very similar to
OpenGL, in fact, one could port large parts of an OpenGL program by simple
function name substitution (the original Half-Life came with a mini
implementation of OpenGL, which wrapped Glide). Over time people abandoned
Glide and 3Dfx got in hard times - it wasn't just because of Glide, that
3Dfx meet its fate, but it was a key factor.
Wolfgang
--
OpenGL tip #42:
How to exactly map texture texels to screen pixels:
<http://preview.tinyurl.com/cgndc8> |
|
|
| Back to top |
|
|
|
| fungus... |
| Posted: Sun Nov 08, 2009 11:03 pm |
|
|
|
Guest
|
On Nov 8, 10:58 pm, "Skybuck Flying" <BloodySh... at (no spam) hotmail.com> wrote:
Quote: Oh sorry, I banned that wolfgang guy... didn't see his reply...
I thought you were asking me for clarification... never mind then ;)
*YOU* banned *US*???
LOL!
--
<\___/>
/ O O \
\_____/ FTB. |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Mon Nov 09, 2009 2:52 am |
|
|
|
Guest
|
There are to ways to compile a shader as for as I know:
1. nvidia's cg compiler which is an executable called cgc.exe
(The compiler has option -o to output assembly.)
2. nvidia's cg dll which is an library/dll cg.dll or so...
My question(s) are:
1. Does the cg dll have api call(s) to get the assembly text after it's
load/compiled ?
2. Does opengl dll/api have api call(s)to get the assemble text after it's
load/compiled ?
3. Does opengl have a shading language compiler executable like cg ?
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Mon Nov 09, 2009 2:58 am |
|
|
|
Guest
|
Oh sorry, I banned that wolfgang guy... didn't see his reply...
I thought you were asking me for clarification... never mind then ;)
Bye,
Skybuck.
"Dave Eberly" <dNOSPAMeberly at (no spam) usemydomain.com> wrote in message
news:1pnJm.6804$ET3.5757 at (no spam) newsfe17.iad...
Quote: "Wolfgang Draxinger" <wdraxinger at (no spam) darkstargames.de> wrote in message
news:4867214.946Emhk5qW at (no spam) narfi.yggdrasil.draxit.de...
Definitely GLSL. Cg is a dead track. (Just it is NVidia's CUDA compared
to
OpenCL).
Would you please explain your statement about Cg? Do you mean the
Cg compiler or the Cg runtime (or both)? Why do you believe it is a
"dead track".
Did you mean to say "Just as it is with NVidia's CUDA ..."? Do you
believe that CUDA is a "dead track"? If so, why?
Thanks for any clarification.
--
Dave Eberly
http://www.geometrictools.com
|
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Mon Nov 09, 2009 3:02 am |
|
|
|
Guest
|
Anyway,
There is this opengl api:
glGetShaderSource
Does it return gl sl language shader ?
Or does it return assembly ?
Maybe I try it out sometime...
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
|
