Can a ARB program(shader pair) use non ARB buffer objects and vertex arrays? Non ARB means with no extension, like NV, ATI, ARB, EXT or other.
Yes, this is perfectly possible. Note that core functionality without the ARB suffix, actually are the ARB extensions, made part of the regular specification. In general there's interoperability between extensions. Also each extension clearly has to state how it interacts with the rest of OpenGL and all other extensions (in existance at the time of specification).
Related
Vulkan GLSL has some additions to OpenGL GLSL.
For example, in Vulkan GLSL there is the push_constant layout qualifier, which does not exist in OpenGL.
layout( push_constant ) uniform BlockName
{
vec4 data;
} instanceName;
Another example is descriptor set bindings. Also don't exist in OpenGL:
layout(set = 0, binding = 0) uniform BlockName
{
vec4 data;
} instanceName;
My question is: considering this is GLSL code (even if it's Vulkan-flavoured), would that code compile in OpenGL? Maybe the OpenGL compiler can ignore those layout qualifiers as long as the #version is something recent enough that Vulkan has been considered in the GLSL spec?
No.
In the GLSL 4.6 spec, you will find both references to OpenGL and Vulkan.
OpenGL-flavoured GLSL won't compile in Vulkan. This one is more obvious, since in Vulkan you are required, for example, to specify either a set-binding pair or push_constant qualifiers for uniforms, and that concept doesn't exist in OpenGL. So those qualifiers would be missing, and thus won't compile.
To answer the actual question:
Vulkan-flavoured GLSL won't compile in OpenGL either.
In the GLSL 4.6 spec you will find the following paragraphs. They explicitly mention that those two cases mentioned in your question should NOT compile.
About push constants (4.4.3):
When targeting Vulkan, the push_constant qualifier is used to declare
an entire block, and represents a set of push constants, as defined by
the Vulkan API. It is a compile-time error to apply this to anything
other than a uniform block declaration, or when not targeting Vulkan.
About descriptor sets (4.4.5):
The set qualifier is only available when targeting Vulkan. It
specifies the descriptor set this object belongs to. It is a
compile-time error to apply set to a standalone qualifier, to a member
of a block, or when not targeting an API that supports descriptor
sets.
I am aware that the c++20 format proposal is a formalization of parts of libfmt, and that libfmt is a compliant implementation of that formalization. However, it's my understanding that libfmt provides additional functionality beyond that specified in the c++20 standard. What are the additional features?
Additional, are the major compiler vendors simply including a subset of libfmt or reimplementing it?
There are a bunch of things in libfmt that are not in C++20 format:
fmt::print() to print directly to stdout. This is proposed in P2093. fmt::printf() also exists but is not proposed in that paper.
fmt::memory_buffer as basically a dynamically sized container that you could format into via fmt::format_to(buf, ...).
Support for formatting ranges and tuples, including fmt::join().
Support for named arguments like fmt::print("Elapsed time: {s:.2f} seconds", "s"_a=1.23);
Compile-time format strings via FMT_COMPILE
I am watching the introduction video's from Apple about Metal and MetalKit.
The sample code for the shaders has these double brackets like [[buffer(0)]] arguments. Why are there two brackets? Does it mean anything or is it just to indicate that there is keyword "buffer" following? There is no such construct in standard c++, is there?
vertex Vertex vertex_func(constant Vertex *vertices [[buffer(0)]],
constant Uniforms &uniforms [[buffer(1)]],
uint vid [[vertex_id]])
Also what would be a good 1 or 2 week fun project as an introduction into GP-GPU? Something manageable for a novice with good math skills but no artistic skills.
These are called attributes, and their syntax and behavior are defined in section 7.6.1 of the C++ standard, Attribute syntax and semantics. They look like this in the grammar:
attribute-specifier:
[ [ attribute-list ] ]
alignment-specifier
The Metal shading language defines numerous attributes that allow you to associate various semantics with variables, struct/class members, and function arguments (including argument table bindings as in your question).
The Metal Shading Language Specification defers to the C++ standard on this, so the C++ standard really is the reference to consult:
The Metal programming language is based on the C++14 Specification
(a.k.a., the ISO/IEC JTC1/SC22/ WG21 N4431 Language Specification)
with specific extensions and restrictions. Please refer to the C++14
Specification for a detailed description of the language grammar.
With this [[ x ]] you declare att that are getting passed between shaders ans CPU
I quote:
The [[ … ]] syntax is used to declare attributes such as resource
locations, shader inputs, and built-in variables that are passed back
and forth between shaders and CPU
Is glBindBuffer equivelent to glBindBufferARB ?
Are the enums (like GL_ARRAY_BUFFER and GL_ARRAY_BUFFER_ARB) equivilent? Can I use non-_ARB enum in glBindBufferARB?
Can I mix + match glBindBuffer() calls with glBindBufferARB()?
ALSO: if a card supports the _ARB extension, does it always support the core GL function - even if its OpenGL version isn't up to date??
In general, it is not legal to do that kind of thing, because core functionality and extensions are not exchangeable, even if they have the same name (one notable example is primitive restart).
However, in this particular case, they happen to be exactly the same with the exact same constants, so... although it's not legal, it is "ok" to use them interchangeably (i.e. nobody will notice if you don't tell them).
You cannot in general assume that if an ARB extension is present that the core funciton will be present as well. There exist many ARB extensions that are there solely to allow OpenGL implementations which cannot implement a full version for some reason to nevertheless provide at least some functionality that the hardware can provide.
I've seen different code snippets using these types, but I haven't seen if they are defined in some <standard header file> or just defined in a "local header file" or even at file level.
So what Im wondering is: Is there any standard header file that defines these types? Or is there some standard definitions that everyone uses that I should copy?
I guess that a possible and common use to these types are representing coordinates, am I wrong?
Is there anything else I should think about if I want to use these to represent positions in a grid? Any reasons why or why not to use them?
EDIT:
Clarification: int2 means a pair of ints, float3 means a triplet of floats.
If these types were predefined somewhere it would be nice to use them instead of having to write it from scratch including the standard algebraic functions (operator+, operator-, etc.).
These types aren't a part of standard C++. They might either be defined in some third-party library, or you're looking at some other dialect or language.
GPU code (Shader languages such as GLSL, Cg or HLSL, or GPGPU stuff like CUDA or OpenCL) typically defines types like these though, as names for the corresponding SIMD datatypes.
They are used in CUDA (and openCL?) where you have specific sized floats and memory usage and alignment is a big deal.
AFAIK there is no standard header file that defines these types.
According to your description int2 means a pair of two ints which can be represented in C++ as std::pair<int, int>.
These types are not standard and I've never seen them. Are you sure they weren't used as (terrible choices of) identifiers instead of types?
Some non-standard types that are quite likely available anyway are int32_t, uint64_t, etc. (These are specified by C99, so most modern C++ compilers also let you use them in C++.)
I stay with the POSIX types defined in <stdint.h>. It seems like everyone defines their own names for things and I've had a project where the names collide. It's become a new paradigm for me to NOT define my own "pet" names for types.