Talking about VAO+VBO... (>GL3)

reader1 · March 25, 2015, 7:38am

With that mental model in mind, I think what Alfonse was trying to indicate to you is that when you create a new GL object (glGenTextures, glCreateShader, etc.), most likely no GPU memory is allocated in this creation (#3). Which makes sense if you think about it because you haven’t told GL anything about how big it is yet. You’ve just said: “give me a new handle that I can refer to this object by”. At this point in your application’s CPU mem (#1) all you have is a GLuint handle (4-bytes). And in the driver (#2), the driver’s probably just allocated a state struct in a state vector for objects of that type which is initialized to a “nothing specified yet” state.

Does that make sense?

We may borrow the concept of class and object. we declare a class, but no mem to be allocated, until an object is defined, the space will be allocated.either in stack or in memory.
However, I though the glCreateShader might be a handle, which might locate in opengl controled memory, it indicates where the shader data will occupy in gpu memory.
then glShaderSource (shaderspace in gpu, shaderdata in opengl) function can transmit the date from opengl mem to gpu mem. then gpu can access to the data.
now as if the return handle of glCreateShader will occupy no space at all?

reader1 · March 25, 2015, 8:16am

With that mental model in mind, I think what Alfonse was trying to indicate to you is that when you create a new GL object (glGenTextures, glCreateShader, etc.), most likely no GPU memory is allocated in this creation (#3). Which makes sense if you think about it because you haven’t told GL anything about how big it is yet.

You’ve just said: “give me a new handle that I can refer to this object by”. At this point in your application’s CPU mem (#1) all you have is a GLuint handle (4-bytes).

And in the driver (#2), the driver’s probably just allocated a state struct in a state vector for objects of that type which is initialized to a “nothing specified yet” state.

Does that make sense?

This is my thinking,
shaderhandle = glCreateShader (); –>the return handle will store in opengl memory.(4byes)
which has address information where the shader data will locate in gpu memory.
glShaderSource() will copy the data (which locate in opengl memory) into gpu memory.
then gpu can input the data into it registers to process according to glsl statement.

Alfonse_Reinheart · March 25, 2015, 10:29am

Your understanding of the potential memory stack here seems wrong.

There are three potential areas of memory involved:

Your memory. This is CPU memory you directly own and can access using the usual rules of C or C++. All variables you declare are in your memory.
OpenGL’s memory. This is memory owned by OpenGL, and you (generally) cannot access it directly. You must use some form of object handle to modify or read data in this memory. Memory of this form comes in two forms:
** CPU memory owned by OpenGL. Some parts of OpenGL objects reside in CPU-addressible memory. While this memory is technically in your address space, you cannot directly access it (not without cheating). You still have to go through OpenGL calls to access it.
** “GPU memory” owned by OpenGL. Some parts of OpenGL objects reside in memory that is easily accessible by the GPU. Different platforms have different kinds of GPU-accessible memory. Some platforms don’t even really make a distinction between the two.

Now that we understand that:

[QUOTE=reader1;1265132]This is my thinking,
shaderhandle = glCreateShader (); –>the return handle will store in opengl memory.(4byes)[/quote]

No. The variable “shaderhandle” is your memory. It’s a regular C/C++ variable containing a 4-byte unsigned integer. The handle itself is in your memory, and it works just like any other value.

The object referenced by the handle is in OpenGL memory. But the four-bytes of the handle itself is in your memory.

Shader objects are in OpenGL’s memory, but they almost certainly are not in GPU-accessible memory (unless the platform makes no distinction).

Because shader compilation (the step immediately following glShaderSource) is purely a CPU operation, putting the shader text into GPU-accessible memory makes no sense, as the CPU is about to access that memory. So virtually all implementations will copy it into CPU accessible OpenGL memory.

Dark_Photon · March 25, 2015, 5:17pm

Yes, for the discrete GPU card case.

Which is controled by gpu address bus. and cpu instruction can also access to it through pci bus to transmit data, I have mentined it before. is it correct?

Yes.

thank you very much for the patient and detail expression. I think we are in the same way.

No problem!

reader1 · March 25, 2015, 6:51pm

[QUOTE=Alfonse Reinheart;1265134]Your understanding of the potential memory stack here seems wrong.
** “GPU memory” owned by OpenGL. Some parts of OpenGL objects reside in memory that is easily accessible by the GPU. Different platforms have different kinds of GPU-accessible memory. Some platforms don’t even really make a distinction between the two.
[/QUOTE]
Your description seems make no different form mine. Are there anything wrong with my grammer in the words in order that make you misunsterstand? The only tiny different is at gpu owned memory.
the gpu memory is bound to be owned and controled by GLSL, which is blended in opengl, of cause you can think it is owed by opengl as well.

No. The variable “shaderhandle” is your memory. It’s a regular C/C++ variable containing a 4-byte unsigned integer. The handle itself is in your memory, and it works just like any other value.

The object referenced by the handle is in OpenGL memory. But the four-bytes of the handle itself is in your memory.

Keep a moment. Here is our gap, Now that the GLint shaderhandle is owned by opengl, it should be in the opengl memory. not in the cpu memory(i.e. operate system momeory, or in your words, your memory); because it is beyond c/c, despite they are all belong to os memory in physical devices. but different part in logical concept.
Many books seem to stand my side, though they are vague to discuss it.

Shader objects are in OpenGL’s memory, but they almost certainly are not in GPU-accessible memory (unless the platform makes no distinction).

I totally disagree to you at this point. What is shader object? the shaderhandle is its behaviour, its represent. and it is in the opengl memory. in which there is a location information of data should be located in the GPU memory.
Thus, we can think shader object site in GPU memory. though it is empty at present step. act as a placeholder in GPU owened memory.
next, the data will be copy into it to fill this space.

Because shader compilation (the step immediately following glShaderSource) is purely a CPU operation, putting the shader text into GPU-accessible memory makes no sense, as the CPU is about to access that memory. So virtually all implementations will copy it into CPU accessible OpenGL memor

I think it should be action of opengl, of cause this makes no different from cpu behavior. However, this is beyond c/c;(compile step).
After compile shader text, the string dta should be in opengl mem, not in GPU mem.
Next opengl api will transmit the data to gpu mem. of cause, all the procedure is controlled by cpu instructions. just like mov gpuaddr, cpuaddr.
as soon as the data entries gpu mem, gpu could menage that now.
Is it clear? this is our different idea.

reader1 · March 25, 2015, 7:01pm

[QUOTE=Dark Photon;1265138]Yes, for the discrete GPU card case.
No problem![/QUOTE]
but how does vao involve vbo is still vague.

Alfonse_Reinheart · March 26, 2015, 12:10am

OK, there are two fundamental misunderstandings at play here. Part of it is word choice, and part of it is just not realizing what different things are. But I think I understand where they are coming from.

Issue One

The first misunderstanding is in the nature of GPUs and GLSL. You seem to think of GPUs as near-exact analogs of CPUs. CPUs have memory; GPUs have memory. CPUs run programs; GPUs run programs. You code CPUs in C or C++; you code GPUs in GLSL.

Therefore, you have come to the conclusion that all GPU operations are governed by GLSL, that all GPU operations are just different functions executing and such. On CPUs, C and C++ code allocate CPU-accessible memory. Therefore, on GPUs, GLSL allocates GPU-accessible memory. OpenGL thus acts as some kind of “blending” agent between C/C++ and GLSL.

That is not how it works.

GLSL does not control what gets rendered. GLSL does not control when rendering happens. The only thing GLSL is used for is to determine shaders. And shaders are very limited in what they do. They operate on certain parts of the rendering pipeline, and they cannot (directly) affect any other parts of that pipeline, outside of the specific values they write as outputs.

They don’t manage the GPU’s memory. They do not schedule GPU operations. All they do happens in certain discrete, fixed locations.

GLSL’s control over GPU operations is in no way similar to C or C++'s control over CPU operations. GLSL is much more like a scripting language than a regular programming language. Like most scripting languages, you compile them as part of executing the application, not as part of compiling it. Like most scripting languages, they operate in a sandboxed environment, which has very limited access to the outside world. Like most embedded scripting languages, they execute exactly and only when the execution environment decides they get to execute.

So if GLSL doesn’t manage GPU resources, who does? The CPU, through the OpenGL implementation, manages them. CPU operations allocate GPU memory. CPU operations decide what gets rendered. CPU commands determine when resources are released. And so forth.

Issue Two

Memory architecture. Let’s say I have a file-static variable in C/C++:


static float myValue = 28.321f;

I can expose a function in that file that allows you to fetch the value of that variable. I can expose a function that allows you to set the value of that variable. But unless I expose a function that returns a pointer or C++ reference to it, your code cannot directly access that memory.

‘myValue’ is in CPU-accessible memory. It is in your process’s address space. But by the rules of C/C++, there is no way to get a valid pointer or reference to it (without breaking those rules).

OpenGL can allocate CPU memory or GPU memory, if a GPU even allows such a distinction. Therefore, “OpenGL memory” could be either one. Or some of both.

Similarly, OpenGL is capable of undertaking “CPU operations”. OpenGL implementations are, at the end of the day, just libraries that you (dynamically) link to. They execute code on the CPU. Some of that code kicks off GPU operations. But other code is purely a matter of CPU work.

Shader compilation is one of those CPU-only things. OpenGL implements compilation, certainly. But it all happens on the CPU, not the GPU.

reader1 · March 26, 2015, 6:46am

Oh, my! you type so many words that must take you much time and mind. I approciate I don’t wish to waste your time. This is only discuss freely. So that you can reply at your free time without too many words.
Most often several words can solve problem.
well, I shall read ti carefully and reply later. Thank yu in advance.

reader1 · March 26, 2015, 8:30am

[QUOTE=Alfonse Reinheart;1265149]OK, there are two fundamental misunderstandings at play here. Part of it is word choice, and part of it is just not realizing what different things are. But I think I understand where they are coming from.
、[/QUOTE]
Which word is choosen incorrectlyt? I shall correct it at once. in order not to take it later.

The first misunderstanding is in the nature of GPUs and GLSL. You seem to think of GPUs as near-exact analogs of CPUs. CPUs have memory; GPUs have memory. CPUs run programs; GPUs run programs. You code CPUs in C or C++; you code GPUs in GLSL.

Therefore, you have come to the conclusion that all GPU operations are governed by GLSL, that all GPU operations are just different functions executing and such. On CPUs, C and C++ code allocate CPU-accessible memory. Therefore, on GPUs, GLSL allocates GPU-accessible memory. OpenGL thus acts as some kind of “blending” agent between C/C++ and GLSL.

Mostly you are right, partly not.

1]When new generationS of GPU develop, it approaches to mimic-CPU. iT has regiesters, simple controller and interface etc.both of them run their own programs.You guess correctly.
But neirher CPU, no GPU has memory. they have only cache in the body.
Both of them can access to mem by their interfaces, address bus and data bus…
Encoding CPU in c/c or opengl, but GPU can be coded mainly by GLSL or other similarly languges, like hlsl.
as if glsl is born by gpu.

2] Mostly gPU is controlled by glsl.especially modern gou.I have ask a questin which was judged by many friends with terrible topic.At last a skillful programmer give out answer," if shaders arguments don’t deal with gpu, gpu will run by its default program", thus why the area in a triangle can form a gradient color.
That means glsl can control gpu.and gpu has also its own fixed prog inside.very seem as that BIOS in mainboard to control CPU.
Opengl is not bkending agent, bocs says it has c style.and glsl was mixed it at last.they are now unit.

reader1 · March 26, 2015, 8:54am

GLSL does not control what gets rendered. GLSL does not control when rendering happens. The only thing GLSL is used for is to determine shaders…

GLSL is born by control GPU, otherwise, it will have no this language.
especially when vertex shader and frag one become to uniform shader.
when rendering happens, of cause, it’s beyond glsl.it’s no other than program ,which is programed by glsl, runs in GPU.(I wish you could not misunderstand me at this step).

And shaders are very limited in what they do. They operate on certain parts of the rendering pipeline, and they cannot (directly) affect any other parts of that pipeline, outside of the specific values they write as outputs.

They don’t manage the GPU’s memory. They do not schedule GPU operations. All they do happens in certain discrete, fixed locations

You are quit right at this spot.They have their own works individually.needn’t affect on the whole like cpu BY C/c…

what is “manage mem”? vao and vbo open an area for data is not “manage”?
I think they are.

reader1 · March 26, 2015, 9:03am

vao and vbo open an area for data is n

vao and vbo should be opengl api action, not glsl.----ccorrect.
as if glsl can not manage mem at present. it’s opengl allocation. you are right

reader1 · March 26, 2015, 9:09am

OpenGL implements compilation, certainly. But it all happens on the CPU, not the GPU.

I agree to you.
but how avo involves vbo is my question. how/

Alfonse_Reinheart · March 26, 2015, 1:25pm

I could tell you to search for it on the OpenGL Wiki (searching for VAO or VBO would lead you to the correct pages), but you’ve already told us that you don’t want to find information yourself.

Um, no. Different GPU elements have actual local memory they can access, not merely cached access to external storage. But yes, in the general sense, they don’t really have on-die storage outside of their registers.

That’s why I called it “CPU-accessible memory” and such. But there’s no reason to be pedantic here; people will shorten it to “CPU memory”, and we all know what they’re talking about.

No, it isn’t.

The best way to understand the relationship between shaders (written in a shading language like GLSL) and the GPU is like this.

Think about the C-standard library function qsort. It takes a function pointer that does the comparison part of the sort. This allows you to control the order used in the sorting operation.

However, no comparison function can make qsort use any other sorting algorithm besides Quicksort (or whatever algorithm that the C-standard library implemented for qsort). The function pointer can only control the ordering of the sort, not the sorting algorithm itself.

Shaders are like the function pointer. They operate only under circumstances controlled by an algorithm that they themselves cannot control. That algorithm is the rendering pipeline, as defined by OpenGL and implemented on the GPU.

So the GPU is not controlled by GLSL.

[QUOTE=reader1;1265157]I have ask a questin which was judged by many friends with terrible topic.At last a skillful programmer give out answer," if shaders arguments don’t deal with gpu, gpu will run by its default program", thus why the area in a triangle can form a gradient color.
That means glsl can control gpu.and gpu has also its own fixed prog inside.very seem as that BIOS in mainboard to control CPU.
[/quote]

If you are referring to thisthread, then you completely misinterpreted what he said. What he said was “If you didn’t specify an interpolation mode in your shaders, the default is smooth interpolation.”

That has nothing to do with the GPU running “by its default program.” It’s simply a language convenience feature; if you don’t specify an interpolation qualifier, GLSL will fill in “smooth” for you. It has nothing to do with how the GPU operates. This was nothing more than a specific circumstance where the language fills in a default. It says nothing about the relationship between GLSL and GPUs.

Can GLSL language elements affect fixed-function GPU processes? Certainly. But it only happens in those places where GPUs allow them to. GLSL can determine the kind of interpolation. It can determine what the outputs from vertex processing are. But GLSL cannot turn on blending. Or depth testing. Or cause the vertex shader to execute over more vertices than the user issued in the rendering command. Or any number of other things.

The GPU is in charge; shaders only get to have responsibility where the GPU allows them to. This is very different from CPUs, which put very few limitations on the programs they execute.

reader1 · March 26, 2015, 7:04pm

No, certainly not. I have to have read them, neither wiji, nor doc tell a key word to show their linking.
gl ova and vbo, and gl object… I browse code I listed, can recite their steps, but still not comprehend where vbo subjects to vao?
If it were only one or two words, why don’t you copy it here? it takes me more than 2monhthes to search them.
<<gen vao, bind it, then gen vbo and bind it…>> and this can also do the trick <gen vbo, bind it, then gen vao, bind it>>
odd enough.

That’s why I called it “CPU-accessible memory” and such. But there’s no reason to be pedantic here; people will shorten it to “CPU memory”, and we all know what they’re talking about.

So it is. ut why did you double my abridge writen on vertexarray and vertexattribarray…in another thread? well, forget it, lets get down to our topic.

haders are like the function pointer.

I agree with what doc said. it’s only an interface, as it were, it’s only part unit of pipline, which accept data from display card memory. indicate other parts of the pipeline how to work according to its arguments. it’s not a pointer, just change the “atate” of work. after a series of stream processing, the result will be sent to fbo, to screen. thus, your expression may be a little incorrect.
so, we can say gpu is controolled by glsl, no gou, will no glsl.

What he said was “If you didn’t specify an interpolation mode in your shaders, the default is smooth interpolation.”

That has nothing to do with the GPU running “by its default program.” It’s simply a language convenience feature; if you don’t specify an interpolation qualifier, GLSL will fill in "smoo

It is just that sentence. ah, you are so careful and serious. Had to admire! you must be one of excellent programmers.

I imagine in my mind, gpu will work according to its biod, mostly like that with cpu in mainboard. and it must be loacated in display card driver and opengl calls it. something like os which take up it and control cpu.
is it right or not is not important. however it can help me with comprehence.
Lets get down to our work, how vao involve vbo? in two or three words.

The GPU is in charge; shaders only get to have responsibility where the GPU allows them to. This is very different from CPUs, which put very few limitations on the programs they execute.

someday, gpu may be elimited, just like fpu. or it reinforces its controller to become more flexibility and strenghen… this is beyond me.

Alfonse_Reinheart · March 26, 2015, 8:08pm

[QUOTE=reader1;1265170]No, certainly not. I have to have read them, neither wiji, nor doc tell a key word to show their linking.
gl ova and vbo, and gl object… I browse code I listed, can recite their steps, but still not comprehend where vbo subjects to vao?
If it were only one or two words, why don’t you copy it here? it takes me more than 2monhthes to search them.
<<gen vao, bind it, then gen vbo and bind it…>> and this can also do the trick <gen vbo, bind it, then gen vao, bind it>>
odd enough.

<snip>

Lets get down to our work, how vao involve vbo? in two or three words.[/quote]

No. OpenGL is complicated. More complicated than it needs to be, perhaps.

The behavior of most blocks of OpenGL code cannot be explained in “two or three words”. When I said that I could copy-and-paste it, I meant the article, not a sentence.

You seem to want short, glib answers to everything. Well, you’re never going to learn OpenGL that way. You have to take the time to understand what each of the parts of that code is doing, yet you keep trying to understand the whole without understanding any of the parts.

To understand that fragment of code, you need to understand:

What it means to generate a VAO name/handle/alias/reference/whatever-you-want-to-cal-lit
What it means to bind a VAO
What it means to generate a buffer object name/handle/alias/reference/whatever-you-want-to-cal-lit
What it means to bind a buffer object
What it means to allocate storage for a buffer object
What it means to bind a buffer object to GL_ARRAY_BUFFER
What glVertexAttribPointer does

That’s a lot of stuff, and there’s no short-cut to learning it. You either take the time to learn what all of the parts mean, or you remain confused.

Because “cpu memory” and “gpu memory” have well-defined and widely agreed-upon definitions. Whereas “vertexarray” and “vertexattribarray” are not terms in common usage anywhere. Furthermore, you have mentioned that there is a language barrier involved, so it’s best to be as explicit as possible. Therefore, I requested clarification as to what you’re talking about.

Your responses have yet to clear things up.

[QUOTE=reader1;1265170]I imagine in my mind, gpu will work according to its biod, mostly like that with cpu in mainboard. and it must be loacated in display card driver and opengl calls it. something like os which take up it and control cpu.
is it right or not is not important. however it can help me with comprehence.[/quote]

It is important if its right or not, because you continue to assume untrue things due to the inaccuracy of this belief.

If you don’t actually know what’s going on under the hood, it’s best to avoid guessing. I speak from experience when I say that it’s easy to be wrong. Just learn it as a black-box process until you can take the time to learn what’s going on inside the box.

reader1 · March 27, 2015, 12:49am

[QUOTE=Alfonse Reinheart;1265173]No. OpenGL is complicated. More complicated than it needs to be, perhaps.

The behavior of most blocks of OpenGL code cannot be explained in “two or three words”. When I said that I could copy-and-paste it, I meant the article, not a sentence.
arn what’s going on inside the box.[/QUOTE]
well, show me a real example, which has two vao, each includes two vbo.
this will be more clear than thousands of words.

reader1 · March 27, 2015, 1:31am

and explain,
the normal sequence should be,

Generate Vertex Array Object
2. Bind Vertex Array Object
3. Generate Vertex Buffer Object
4. Bind Vertex Buffer Object

but when modify like this,
3. Generate Vertex Buffer Object
4. Bind Vertex Buffer Object

Generate Vertex Array Object
2. Bind Vertex Array Object
it still works well.
why?

Alfonse_Reinheart · March 27, 2015, 5:28am

[QUOTE=reader1;1265177]and explain,
the normal sequence should be,

Generate Vertex Array Object
2. Bind Vertex Array Object
3. Generate Vertex Buffer Object
4. Bind Vertex Buffer Object

but when modify like this,
3. Generate Vertex Buffer Object
4. Bind Vertex Buffer Object

Generate Vertex Array Object
2. Bind Vertex Array Object
it still works well.
why?[/QUOTE]

It works for the same reason why this does:



Object1 *a;
Object2 *b;

void Standard()
{
  Object1 *ptr1 = new Object1;
  a = ptr1;
  Object2 *ptr2 = new Object2;
  b = ptr;
}

void Modify()
{
  Object2 *ptr2 = new Object2;
  b = ptr;
  Object1 *ptr1 = new Object1;
  a = ptr1;
}

reader1 · March 27, 2015, 6:36am

[QUOTE=Alfonse Reinheart;1265182]It works for the same reason why this does:



Object1 *a;
Object2 *b;

void Standard()
{
  Object1 *ptr1 = new Object1;
  a = ptr1;
  Object2 *ptr2 = new Object2;
  b = ptr;
}

void Modify()
{
  Object2 *ptr2 = new Object2;
  b = ptr;
  Object1 *ptr1 = new Object1;
  a = ptr1;
}

[/QUOTE]
Where is ptr? is it ptr2?
curious, what does it mean for you to put down such odd codes?
What relationship between the codes and the vao?

Alfonse_Reinheart · March 27, 2015, 6:49am

Yes, that was a typo; it is supposed to be [var]b = ptr2;[/var] in both cases. Though it was unintentional, perhaps you understand better what it’s like for the rest of us to decipher your posts

[QUOTE=reader1;1265184]curious, what does it mean for you to put down such odd codes?
What relationship between the codes and the vao?[/QUOTE]

Well, you’re supposed to work that one out for yourself. It’s an analogy. Each line in those two functions represents one of the steps in your post. And therefore, you can see why changing the order of operations doesn’t affect the result.