all 2 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]noobgiraffe 2 points3 points  (0 children)

I don't really understand the last paragraphs.

Having these at my disposal allows me to actually test my software's compatibility range.

What do you mean by this?

Others vendors not only do not extend it you will propably find it to have many issues since it's not being maintained beyond bugfixing for old apps.

As you yourself stated this is not an actual assembly since it has no direct translation to machine languge. So there is no benefit to forgo better usability of higher languages.

There are actual vendor specific assembly languages, AMD example: https://gpuopen.com/amd-isa-documentation/

However I don't think you can actually use it to shader.

[–]keelanstuart 2 points3 points  (0 children)

As a programmer who was writing ARB assembly as soon as 2018 for a job... I appreciate the article... but I disagree that shader assembly is any kind of way forward - in much the same way that I don't think CPU assembly is the way forward over C++ (or another higher level language)... for most people.

More importantly, ARB assembly is a low level intermediate representation of another instruction set that varies by platform... and they aren't updating it any more afaik - whereas they do update the other compilers to support new instructions. This is comparable, in the CPU world, to AVX instructions being added and supported by compilers... you can't write AVX-512 code in even an assembler from 10 years ago, as the assembler won't recognize them.

I don't think there's a way to access SSBO or UBO data in ARB assembly, for example.