ARB Assembly Level

It was never part of Core OpenGL, but it's usage is low, it's preferred to use GLSL.

Besides ARB Assembly hasn't got any updates, only nvidia maintains extensions to it in NV_*_program2/3/4. So don't expect any modern capabilities in ARB Assembly.

As far as I know, gpu_program_4 is now EXT and should be supported by ATI. You can compile Cg shader to all *_program_* assembly.

Quote:

Original post by zorbad As far as I know, gpu_program_4 is now EXT and should be supported by ATI. You can compile Cg shader to all *_program_* assembly.

I couldn't find EXT_gpu_program4 in the OpenGL Extension Registry, are you sure it exists?

Well, it's actually gpu_shader4

http://www.opengl.org/registry/specs/EXT/gpu_shader4.txt

Quote:

Original post by zorbad Well, it's actually gpu_shader4

No, GL_EXT_gpu_shader4 adds integer support, bit operations, bindable fragment outputs and integer coordinate addressing to GLSL, and it's core in 3.0. No mention of ARB assembly.

Ok thank's for your reply.
So it isn't recommended to use the assembly level?
But I didn't understand why.
They're small but they also affect the performance in a programm
strongly.Shaders are small Hotspots in a programm.

Just like someone else said, only nvidia maintains their own low level NV extensions.
If you want to target a wider audience (ATI/AMD), then GLSL is the only option.
Even in DX10, the only option is HLSL.
The only problem is takes a lot of time to compile a lot of GLSL shaders
http://www.opengl.org/wiki/GLSL_:_common_mistakes#Compile_GLSL

But what about the instructions limit.
What is an instruction. I think it's one assembly instruction but I dunno how the driver(or the compiler respectively) will optimize my code. So the number of Instructions is less predictable while coding with a high level language.
Is there any way to forebode the number of Instructions while coding with GLSL or HLSL respectively?



Please excuse my under-averaged English. It's not my mother tongue.(^_^)

HuntsMan: well, thats a bad news.

Chuck300: instruction limit was a big problem in PS 2.0 times (only 64 ALU/32 TEX), but now you can code so many instructions in the shader that it will not be realtime anymore. ;)

Again, OpenGL doesn't make it easy for programmers. This is why D3D is better.

What you need to do is compile. If it didn't compile, then you try a simpler version of your shader.
Or, it can compile (on ATI/AMD), but it says "it will run in software since hw limits exceeded" so you search for the word software and tell the user his video card sucks.

Yes, this is mostly a problem on SM 2.0 GPUs.

GLSL was never fully meant to SM2.0 cards, much features supported by GLSL aren't supported by SM2.0 cards, such as dynamic branching, vertex texture fetch, etc. For that cards just use the ARB Assembly path and you'll be fine.

Thanks a lot for this helpful replies.
My Engine should run on slower hardware, too.
So I'll have to implement some assembly Shader as fall back.
But I'd really like to know who decided to deprecate the assembly shader.
There are just disadvantages:
- Less control over the Instruction Limit.
- More complicated optimizations.
- Sometimes much longer Compilation times.
- You have to work on a high-level language so it's difficult to
insert/exchange/change/delete etc. parts of the code. That causes:
- More complicated Effect-libraries.
- More complicated Shader management libraries.


I've tried to implement an Shader management system working with preprocessor commands.
It was very complicated to add one part/effect to the shader,
because in a high level language there are very much dependencies and constructs which have to be changed and/or modified.

And I think it's against our 'holy' programming rules to change something (very) high-level to cause an little low-level effect.
That's just not the way we (programmers) are usually thinking.

Quote:

Original post by Chuck300 But I'd really like to know who decided to deprecate the assembly shader.

As i said, you can't deprecate something which was always an OpenGL Extension. And besides, you can guess why 99.9% of the programmers in the world work with high level languages, the same reason applies to shading languages.

DirectX10 applies the same principle as OpenGL, as the only way to submit shaders is through HLSL, and i haven't seen any complain about that.

Quote:

Original post by Chuck300 But I'd really like to know who decided to deprecate the assembly shader. There are just disadvantages: - Less control over the Instruction Limit. - More complicated optimizations. - Sometimes much longer Compilation times.

Okay, I will give you those - they are arguable (especially the second one), but I won't dispute them. These however:

Quote:

- You have to work on a high-level language so it's difficult to insert/exchange/change/delete etc. parts of the code. That causes: - More complicated Effect-libraries. - More complicated Shader management libraries.

are pure nonsense. Have you ever *tried* to implement a meaningful shader in assembly? Say, an atmospheric scattering post-process in a deferred renderer?

Quote:

I've tried to implement an Shader management system working with preprocessor commands. It was very complicated to add one part/effect to the shader, because in a high level language there are very much dependencies and constructs which have to be changed and/or modified.

Source-level dependencies in high-level languages more difficult than register allocation/dependencies?

Quote:

And I think it's against our 'holy' programming rules to change something (very) high-level to cause an little low-level effect. That's just not the way we (programmers) are usually thinking.

A lot of shaders these days are not some 'little low-level effect', and I would say that any shader with over a few hundred instructions is completely unmanageable at the assembly level.

@swiftcoder:
Thanks for your fair comment.
I'll think about it.
Maybe I'm thinking a little naive.

But I think it would be great if at least some kind of inline assembly could be provided.
But maybe that's the nextgen of shaders with templates and classes etc.

inline assembly? that will never happen.

Either use GLSL or forget OpenGL.

Hi,
I found a good solution for my problem.
There is not only assembly shader support provided by Nvidia.
AMD has it's own intermediate language. All there shaders are compiled first to this IL and then to assembly code.
have a look at this pdf:
http://coachk.cs.ucf.edu/courses/CDA6938/s08/AMD_IL.pdf
there is also an official manual:
http://developer.amd.com/gpu_assets/Intermediate_Language_Specification--Stream_Processor.pdf

Quote:

Original post by Chuck300 I found a good solution for my problem.

So now you are going to implement shaders in 2 assembly languages (NVidia and ATI), as well as GLSL for other vendors (Intel, VIA, PowerVR, etc.)? Not really seeing the solution in all that...

Your "solution" is actually worse than the problem. Are you having shader performance problems? Why program in Assembly?