Originally posted by Humus: On the other hand, the ISV people don’t risk losing millions in sales because their bar was a few pixels shorter than the competition on a chart on Toms Hardware Guide.
Well, and I guess that is the biggest argument for making the hardware/platform dependent driver side as low-level as possible and then layer on top the high level stuff which seem to be the directx approach. Imo the ARB and IHVs should also use a similar approach to make good high-level features faster and wider available. GLSL showed a very disappointing development with the OpenGL API: late introduction of high level, modern GPU features already widely available on Direct3d, followed by a very long and buggy implementation phase. No good combination.
Originally posted by Korval:
On a personal note, OpenGL and the ARB should spend absolutely no time finding solutions for the GPGPU people. If they want to hack their graphics cards into CPU’s, fine, but they shouldn’t expect a graphics library to help them at all.
I disagree with that. After all graphics is also just solving an integral equation called global illumination equation. The methods used in graphics can also used in many other domains and vice versa. So imo for a good future development of the API it should also follow the path of the hardware to providing primitives (good hardware acceleration streaming computations) rather than solutions. In the end the graphics domain will also benefit from it more than from a bunch of solutions called graphics API.
After all graphics is also just solving an integral equation called global illumination equation. The methods used in graphics can also used in many other domains and vice versa. So imo for a good future development of the API it should also follow the path of the hardware to providing primitives (good hardware acceleration streaming computations) rather than solutions.
OpenGL is a Graphics Library, not a GPGPU library. If something is found to be useful for graphics work, that happens to be of great interest to the GPGPU people as well, it can be brought in. However, if it is something that exists solely for the GPGPU crowd, it should not even be considered.
You don’t see people asking DirectSound or OpenAL to do graphics work. Even though, with some finesing of the internals, it could function as a weak GPU.
Originally posted by Korval: OpenGL is a Graphics Library, not a GPGPU library. If something is found to be useful for graphics work, that happens to be of great interest to the GPGPU people as well, it can be brought in. However, if it is something that exists solely for the GPGPU crowd, it should not even be considered.
Although I can think of some nice features that would both serve the graphics and the GPGPU people, I have to agree with Korval.
GPGPU people, myself included, should be grateful that there is a relatively cheap and fast commercial platform to program on compared to very expensive custom made ASICS.
You don’t see people asking DirectSound or OpenAL to do graphics work. Even though, with some finesing of the internals, it could function as a weak GPU.
Once I tried asking my floppy drive to compute me some SH coefficients, but all it did was format my commander keen install disk.
Just for the record. I think an asm interface rox and is a good idea to always have one imo.
Originally posted by Humus:
If we’re talking about an intermediate language I might be in iff it doesn’t destroy the semantics of the original shader. But then again, then we’re not really saving a whole lot more than the parsing.
This is a very important point. Cass, in what way do you feel glsl is too high level at the moment? Obviously, the D3D shader models were too low level since new ones keep popping up (2.0b is a good example). For a low level language it seems reasonable to put the abstraction at about C’s level (it was designed to be a portable assembler after all), but that’s roughly where glsl is today.
Originally posted by harsman:
[b] [quote]Originally posted by Humus:
If we’re talking about an intermediate language I might be in iff it doesn’t destroy the semantics of the original shader. But then again, then we’re not really saving a whole lot more than the parsing.
This is a very important point. Cass, in what way do you feel glsl is too high level at the moment? Obviously, the D3D shader models were too low level since new ones keep popping up (2.0b is a good example). For a low level language it seems reasonable to put the abstraction at about C’s level (it was designed to be a portable assembler after all), but that’s roughly where glsl is today.[/b][/QUOTE]I don’t think GLSL is too high level as a high-level shading language, I think GLSL is too high level as a compile target.
The low level abstractions aren’t too low-level, they actually represent what the hardware is capable of. If you try to compile an HLSL shader to a PS2.0b shader and it fails, you’ll know it’s because the compiler couldn’t make it work given the rules of that model. If you try to do the same thing in GLSL, it’ll just fail and maybe give you some text info, but at that point it’s too late.
One is a hardware abstraction, the other is just an abstraction.
I disagree that the low-level language just saves the parsing. That’s a gross oversimplification. Compilers are more complex than that. Today’s shader models are simple enough perhaps to fool yourself into thinking that shader compilers will always be simple. But you are fooling yourself if you think that.
The low level abstractions aren’t too low-level, they actually represent what the hardware is capable of.
I’m sure 3DLabs doesn’t think so. Their hardware isn’t a near 1:1 mapping from D3D shaders to their hardware. Their hardware is fairly unorthadox.
The problem with ISA’s, one that we’re faced with in the x86 world, is when the ISA just doesn’t match the hardware anymore. Look at the P4; a pretty significant portion of the chip is dedicated to transforming x86 into the low-level machine opcodes; effectively, it has a compiler. C/C++ optimzing compilers are designed to work around the weaknesses of the x86 ISA.
The primary thing the x86 architecture buys you is backwards compatibility; the ability to install and run DOS on a P4 (other hardware issues aside).
Certainly, the glslang approach can function. In a perfect world, it works. However, the ISA approach has problems too, as 3DLabs’s hardware doesn’t match the ISA at all. The high-level information that was lost in compilation is very useful to them. The fact that the user asked for a vec2 rather than a vec4 has meaning for their optimizer; losing this information is bad for them and their implementation. Now, they have to write code to figure out whether each 4-vector float param is used as a 2-vector or not.
You need an ISA with the richness of a higher-level language to be able to allow compilers for disperate hardware to optimize reasonably. ARB_vp and fp can’t do that; they’re too bound to the traditional ideas of a vector-based system. As such, it’s a bad general shader ISA.
Originally posted by Korval:
You need an ISA with the richness of a higher-level language to be able to allow compilers for disperate hardware to optimize reasonably. ARB_vp and fp can’t do that; they’re too bound to the traditional ideas of a vector-based system. As such, it’s a bad general shader ISA.
ARB_vp and ARB_fp are fine targets for scalar designs as long as swizzling and masking are
supported (which they are).
Existing hybrid microarchitectures that have 3+1, 2+2, and 4+1 operating modes take great advantage of being able to specify 1,2,3,and 4 component operations clearly and succinctly in the ISA.
I’m not arguing for a specific ISA here, by the way. Just that there is goodness to having a low-level. If a vendor can’t support the D3D ISA well, they’re going to have problems selling hardware, I think.
Originally posted by cass: If you try to compile an HLSL shader to a PS2.0b shader and it fails, you’ll know it’s because the compiler couldn’t make it work given the rules of that model. If you try to do the same thing in GLSL, it’ll just fail and maybe give you some text info, but at that point it’s too late.
Or it may just work because your compiler knew the hardware, rather than an artificial model that’s a common denominator of a class of hardware from different vendors.
Originally posted by cass: I disagree that the low-level language just saves the parsing. That’s a gross oversimplification. Compilers are more complex than that. Today’s shader models are simple enough perhaps to fool yourself into thinking that shader compilers will always be simple. But you are fooling yourself if you think that.
Exactly what step beyond parsing would using a semantics-preserving IL save? If you have a shader with all the semantics, you still have the compilation step ahead.
The low level abstractions aren’t too low-level, they actually represent what the hardware is capable of. If you try to compile an HLSL shader to a PS2.0b shader and it fails, you’ll know it’s because the compiler couldn’t make it work given the rules of that model. If you try to do the same thing in GLSL, it’ll just fail and maybe give you some text info, but at that point it’s too late.
Whooooooooaaaaaaaa! Fail?
It’s suppose to run in software mode.
Originally posted by Humus: Or it may just work because your compiler knew the hardware, rather than an artificial model that’s a common denominator of a class of hardware from different vendors.
“It MAY just work” is not a particularly fun place for developers to target. Common denominators are critical for writing code that you know will work.
Exactly what step beyond parsing would using a semantics-preserving IL save? If you have a shader with all the semantics, you still have the compilation step ahead.
Maybe I don’t know what you mean by “semantics-preserving IL” then. The low-level that I’m talking about couldn’t simply be disassembled back into the original high-level shader. Old c-front style C++ compilers used C as their compilation target of C++, but the good ones still did tons of optimization in the c+±>c compilation.
In CPU-land the hardware is only aware of the ISA. Any correlation of a high-level language to the hardware is a software problem. You could argue that the ISA can be clunky and inefficient, but the market seems to have decided that maintaining x86 compatibility is worth adding extra hardware support. And not having x86 support jeopardizes the viability of the product.
I don’t see how the GPU world is immune to those same forces.
Originally posted by V-man: Whooooooooaaaaaaaa! Fail?
It’s suppose to run in software mode.
If your OBJECT_COMPILE_STATUS_ARB or OBJECT_LINK_STATUS_ARB are FALSE, then all bets are off.
The docs state that these kinds failures must be limited. But you have to deal with it, even if you think it’s the driver’s fault.
In any case, if you’re on the hairy edge of being able to run in hw on your min-spec system and a compiler change (driver update) causes you to fall off the fast path, you probably want to know it. If your game/app suddendly started hitting sw fallback all the time, your customers would not be happy.
Originally posted by cass:
In CPU-land the hardware is only aware of the ISA. Any correlation of a high-level language to the hardware is a software problem. You could argue that the ISA can be clunky and inefficient, but the market seems to have decided that maintaining x86 compatibility is worth adding extra hardware support. And not having x86 support jeopardizes the viability of the product.
[/QB]
I’m not so sure that the market has decided. I see much more a OS vendor lock in to windows which has a naturally monpoly and is only supporting activly one plattform. If the OS vendor is changing the ISA that software developer does too. Look at apple. I think this is bad. Assembly support is good for the old ones and bad for the innovators because the transactionscosts for the ISA change are to high to get a critical mass to show the advantage of the new platform. A higher level interface in this sense is much better for the customizers and the developers in the long run. Look at Unix/Linux/BSD etc., its a high level interface and there is competition. There are other problems but that is about its maybe to high level. So the question how high level should the interface be. I find GLSL is at the right level but the error/warning/debug interface should be much more standardized(the info log(XML? who cares)). But maybe we should see GLSL more as a target interface and not so much as programer interface so I’m not so sure about C syntax. I mean give the hardware developer the many informations but don’t do sugar for the developer in the interface(for example automated casts). This is IMHO the job of other tools.
Originally posted by V-man:
[b]OK, a failure can happen.
What is the solution?
ARB_vp/fp provided query functions. Do the same for GLSL?
The developer educates himself on what all the GPUs can do and writes various shaders?
Provide feature to turn off optimization to get a static well defined behavior for all drivers of the same GPU?
Caps for all the instrinsic functions in GLSL?
(Should I avoid noise function)
I think #2 is the best. #1 isn’t bad cause it helps #2. I have a feeling #1 will never be intoduced.
Everyone hates #4.[/b]
I don’t think there’s really any substitute for #2 today, and #3 only makes sense if you’re using GLSL as a compile target. Otherwise you lose all the advantages of writing in a high-level language.
Originally posted by marco: I’m not so sure that the market has decided. I see much more a OS vendor lock in to windows which has a naturally monpoly and is only supporting activly one plattform. If the OS vendor is changing the ISA that software developer does too. Look at apple. I think this is bad. Assembly support is good for the old ones and bad for the innovators because the transactionscosts for the ISA change are to high to get a critical mass to show the advantage of the new platform. A higher level interface in this sense is much better for the customizers and the developers in the long run. Look at Unix/Linux/BSD etc., its a high level interface and there is competition. There are other problems but that is about its maybe to high level. So the question how high level should the interface be. I find GLSL is at the right level but the error/warning/debug interface should be much more standardized(the info log(XML? who cares)). But maybe we should see GLSL more as a target interface and not so much as programer interface so I’m not so sure about C syntax. I mean give the hardware developer the many informations but don’t do sugar for the developer in the interface(for example automated casts). This is IMHO the job of other tools.
You make good points, Marco. I think the point I am making about the market forces correspond quite well to what you say. Stability, extensibility, and backward compatibility are all critical aspects of this.
The core of these ideas have a software basis (Win32 APIs for example), but they also have a hardware basis (stable ISA and ABI).
OpenGL has traditionally taken this route. Code written for OpenGL 1.0 will still compile and run well more than 10 years later. The basic hardware abstraction is stable, extensible, and backward compatible. But it is still a low-level hardware abstraction.
My assertion is that there will be natural pressure to have a low-level programmable interface for OpenGL. I’m not saying it’ll necessarily look more like ASM than C, but that a tool chain external to the driver will treat it as a compile target.
This is all speculation, of course, but it’s why I think ARB_fp and ARB_vp will be around for quite a while.
Originally posted by cass: “It MAY just work” is not a particularly fun place for developers to target. Common denominators are critical for writing code that you know will work.
Everything can break. GLSL is no different than VBOs, blending or other features. And things can most definitely run in software. This is no different either. There’s no guarantee that Quake3 will run in hardware on future GPUs either. Somehow developers are able to deal with this, and I’m don’t see how GLSL changes that.
Maybe I don’t know what you mean by “semantics-preserving IL” then.
I mean an IL that doesn’t hide the intent of the programmer. It should be possible to reconstruct a shader that’s not too different from the original shaders. That means that no if-statements are replaced with SLT/MUL, no loops unrolled, no register renaming etc.
I don’t see how the GPU world is immune to those same forces.[/QB]
We don’t need to go there in the first place. The CPU world ended up there because of historical reasons and now we’re stuck with x86 because it’s darn near impossible to change due to the abundance of old software that needs to work. GPUs on the other hand have the unique position of not being interfaced directly but through an API, which doesn’t lock us in as much. Putting an assembly language interface there on the other hand easily ties our hands for future generations, and I think that’s a bad idea. Just as what was good for 8086 isn’t all too great for the Pentium4 I don’t think what’s a good representation for R420/NV40 will be a good representation for R800/NV80.
Originally posted by Humus: Everything can break. GLSL is no different…
Everything is not equally susceptible to breakage. More complex things are more difficult and time consuming to implement correctly and more likely to break.
GLSL is more fragile than ARB_vp/fp in this regard. Quality implementations of the ASM interfaces were available as soon as products that supported them shipped. GLSL implementations have taken much longer to surface and their quality generally doesn’t match the ASM.
Originally posted by Humus: We don’t need to go there in the first place. The CPU world ended up there because of historical reasons and now we’re stuck with x86 because it’s darn near impossible to change due to the abundance of old software that needs to work. GPUs on the other hand have the unique position of not being interfaced directly but through an API, which doesn’t lock us in as much.
You don’t think we need to go there, but MS does. Their ISAs have required regular revamping in the first few generations of programmable shaders, but when they stabilize (as they are doing rapidly), GPUs will have a lot of legacy code that will need to be maintained indefinitely.
OpenGL may choose to never embrace the ISA approach, of course, but there are several good reasons why it might.
I feel like I’m beginning to repeat myself on this thread, so I’ll probably refrain from further posts.
I have enjoyed following this thread - it’s good to hear the thoughts and opinions of ISVs. For the most part I already know the opinions of IHVs.
Originally posted by sqrt[-1]:
[b]
That and possibly a few others from ARB_fragment_program on errors:
Error line number
“Reason for failure enum” (ie enums for too many instructions, too many texture lookups, too many dependant texture lookups etc)[/b]
I second that. I’m doing some developement in the direction of high level and component based render algorithm description. Therefore I need to make as many as possible configuration decisions automatically for which I need machine manageable (== specified) informations about shader components.
An additional error information which would be very helpful in this context is reason for link errors. Like an enum for undefined function and a mechanism for querying information for the undefined function (name and parameter names/types).
I think in the medium term complete shaders most likely won’t be written by hand but will be generated automatically out of a huge collection of shader components based on some constraints (hardware, speed, quality). Unfortunately till now glsl (resp. glsl spec) is very unusable for this context
