PDA

View Full Version : Talking about VAO+VBO... (>GL3)



reader1
03-24-2015, 06:08 AM
We create a vao, which is more or less like a pointer. where is it? in os mem or in graphic card mem?
then generate two or more VBO in graphic card mem, which is cantained by the VAO.
How shall we distinguish them belong to which vao without coding sequence.?
say, needn't bind, gen, bind, gen....

2]how to transmit the data in shaders to conresponding VBO distintly and easily?
let prog knows who is who simply and easily?

look at the relative prog, is it very complex?


set up vbo, one is for vertex, one is color;
glGenBuffers(2,vboHandle);
bind to be effective and transmit vertex and color data into it. the data is in shaders*.text defined.
//////////////////

GLuint vboHandles[2];
glGenBuffers(2, vboHandles);
GLuint positionBufferHandle = vboHandles[0];
GLuint colorBufferHandle = vboHandles[1];

//bind to use it.
glBindBuffer(GL_ARRAY_BUFFER,positionBufferHandle) ;
glBufferData(GL_ARRAY_BUFFER,9 * sizeof(float),
positionData,GL_STATIC_DRAW);

glBindBuffer(GL_ARRAY_BUFFER,colorBufferHandle);
glBufferData(GL_ARRAY_BUFFER,9 * sizeof(float),
colorData,GL_STATIC_DRAW);

glGenVertexArrays(1,&vaoHandle); //Vertex Array Object
glBindVertexArray(vaoHandle); /* Bind VAO as the current used object */

/* Enable attribute index 0 as being used */
glEnableVertexAttribArray(0);
glEnableVertexAttribArray(1);

glBindBuffer(GL_ARRAY_BUFFER, positionBufferHandle); //see below
glVertexAttribPointer( 0, 3, GL_FLOAT, GL_FALSE, 0, (GLubyte *)NULL );
/* Specify that our coordinate data is going into attribute index 0, and contains 3 floats per vertex */

glBindBuffer(GL_ARRAY_BUFFER, colorBufferHandle);
glVertexAttribPointer( 1, 3, GL_FLOAT, GL_FALSE, 0, (GLubyte *)NULL );

reader1
03-24-2015, 06:26 AM
glBindBuffer(GL_ARRAY_BUFFER,positionBufferHandle) ;
glBufferData(GL_ARRAY_BUFFER,9 * sizeof(float),
positionData,GL_STATIC_DRAW);

[[[glBindBuffer(GL_ARRAY_BUFFER,colorBufferHandle);
glBufferData(GL_ARRAY_BUFFER,9 * sizeof(float),
colorData,GL_STATIC_DRAW); ]]]/// Do these two statements overelaborate?
////could we use one like this,
glBindBuffer(GL_ARRAY_BUFFER,pcBufferHandle[]);
glBufferData(GL_ARRAY_BUFFER,9 * sizeof(float),
pcData[], GL_STATIC_DRAW) //////to instead of that?


glGenVertexArrays(1,&vaoHandle); //Vertex Array Object
glBindVertexArray(vaoHandle); /* Bind VAO as the current used object */

/* Enable attribute index 0 as being used */
glEnableVertexAttribArray(0); //are the two vague? one hardly understand from the functions.
glEnableVertexAttribArray(1);

glBindBuffer(GL_ARRAY_BUFFER, positionBufferHandle); //agine repeat!
glVertexAttribPointer( 0, 3, GL_FLOAT, GL_FALSE, 0, (GLubyte *)NULL );
/* Specify that our coordinate data is going into attribute index 0, and contains 3 floats per vertex */

glBindBuffer(GL_ARRAY_BUFFER, colorBufferHandle);// agai and again...
glVertexAttribPointer( 1, 3, GL_FLOAT, GL_FALSE, 0, (GLubyte *)NULL );

how about if we would have more than one vao? does that very overelaborate?
are we operating the gpu or write a nature program?

reader1
03-24-2015, 06:43 AM
and in this main function, we can even hardly find how data link with vertex.text shader statement:
in vec3 VertexPosition;

despite we feel it will locate in vbo(0); why don't instruct it distinctly? too zigzag...

Alfonse Reinheart
03-24-2015, 07:24 AM
We create a vao, which is more or less like a pointer

No, it isn't "like a pointer". It's more like a C++ reference. It's an opaque handle that refers to an object owned by OpenGL.


How shall we distinguish them belong to which vao without coding sequence.?
say, needn't bind, gen, bind, gen....

It's not clear what you mean by that. You "distinguish" between VAOs because you created them and filled them with data. Therefore you ought to know which one has which data in it.


/// Do these two statements overelaborate?
////could we use one like this,

No. Such a function would be pointless. It only works in your case because the two buffers you're trying to allocate just so happen to have the exact same size. If your colors were unsigned bytes, like most people use, then you wouldn't be able to use it.

Equally importantly, you should probably interleave your vertex data (https://www.opengl.org/wiki/Vertex_Specification_Best_Practices#Formatting_VBO _Data) unless you have a good reason not to.


//agine repeat!

... so? You're binding it for two completely different purposes. In the first case, you're binding it to allocate storage to it. In the second case, you're binding it to put it into a VAO.


despite we feel it will locate in vbo(0); why don't instruct it distinctly?

Because you didn't "instruct it distinctly (https://www.opengl.org/wiki/Vertex_Shader#Inputs)". There are two ways to do that, and you have to use one of them if you want to be certain that it will get attribute index 0.

reader1
03-24-2015, 07:59 AM
How to use this multi -quote?

Dark Photon
03-24-2015, 06:24 PM
We create a vao, which is more or less like a pointer. where is it? in os mem or in graphic card mem?
then generate two or more VBO in graphic card mem, which is cantained by the VAO.

Like your first question on your shader program thread, you're asking good questions here. However, you need to understand each abstraction first: What's it used for? What's in it? How do you build one? Please do read up (in a decent OpenGL book, the OpenGL wiki, the OpenGL spec, modern OpenGL tutorial, or somewhere with solid OpenGL information) a bit more about what these objects you're asking about are. I think that will answer quite a few of the questions you're asking.

Each of these abstractions (VAO, VBO, shader, shader, program, etc.) is typically exposed to you as an object handle (usually a GLuint). This is not a pointer. It's also not a reference. It's more akin to a key in a dictionary (think std::map), though it could be an index into an array (think std::vector). The point is "to you" it's just an integer that is a handle. It means nothing to you, and you can do nothing with it but pass it to OpenGL. But the GL driver (or GPU) can use this to quickly lookup the state data for that OpenGL object abstraction (e.g. VAO, VBO, shader, shader program, etc.) for its internal processing.

Then, once you understand the abstractions, as to where each lives...

You need to realize that where each object lives (e.g. CPU memory in the driver, GPU memory, etc.) is abstracted behind the OpenGL API in most cases! We can talk about where each probably lives, and under what circumstances, and what you as a developer can do to influence that to optimize performance (which may vary by GPU architecture and vendor). But where it actually "does" live is ultimately up to the OpenGL driver.

reader1
03-24-2015, 07:29 PM
Like your first question on your shader program thread, you're asking good questions here. However, you need to understand each abstraction first: What's it used for? What's in it? How do you build one? Please do read up (in a decent OpenGL book, the OpenGL wiki, the OpenGL spec, modern OpenGL tutorial, or somewhere with solid OpenGL information) a bit more about what these objects you're asking about are. I think that will answer quite a few of the questions you're asking.

Each of these abstractions (VAO, VBO, shader, shader, program, etc.) is typically exposed to you as an object handle (usually a GLuint). This is not a pointer. It's also not a reference. It's more akin to a key in a dictionary (think std::map), though it could be an index into an array (think std::vector). The point is "to you" it's just an integer that is a handle. It means nothing to you, and you can do nothing with it but pass it to OpenGL. But the GL driver (or GPU) can use this to quickly lookup the state data for that OpenGL object abstraction (e.g. VAO, VBO, shader, shader program, etc.) for its internal processing.

a handle should occupy a byte or more in mem, but it was told it has no space in mem. Alfonse siad in his 2 reply it was only a name. Does it has a space in cpu or gl mem?
if it were not, that means it exists or harnessed only in compiler?



Then, once you understand the abstractions, as to where each lives...
it should be lived in each bind, after a new bind, the before will be broken.


You need to realize that where each object lives (e.g. CPU memory in the driver, GPU memory, etc.) is abstracted behind the OpenGL API in most cases! We can talk about where each probably lives, and under what circumstances, and what you as a developer can do to influence that to optimize performance (which may vary by GPU architecture and vendor). But where it actually "does" live is ultimately up to the OpenGL driver.
as if opengl is for cpu, but only glsl is for gpu, dispect they are blended now.

reader1
03-24-2015, 07:37 PM
Like your first question on your shader program thread, you're asking good questions here. However, you need to understand each abstraction first: What's it used for? ultimately up to the OpenGL driver.
in ifact, They are one sample. here just contine to that one. and the sample is also from one of the books.
I marked in the 2rd floor, I think it seems to overellaborate sometime. too much repeat bind, bind, despite its a good procedure to operate the gpu works. as if it were a script, not a language?

Alfonse Reinheart
03-24-2015, 08:17 PM
OK, don't put your reply inside the block quotes. That makes it exceedingly difficult to see what's you and what's someone else. Put the text that's actually a quote in the quote block,, then reply to it outside the quote. If you need another quote, then start another one.

Also, "dispect (http://dictionary.reference.com/misspelling?term=dispect)" is not a word.


a handle should occupy a byte or more in mem, but it was told it has no space in mem. Alfonse siad in his 2 reply it was only a name. Does it has a space in cpu or gl mem?

What do you mean by "it"? If you're talking about the GLuint value itself, yes, it is a 32-bit unsigned integer. Therefore, it takes up 32-bits of space in whatever data structures or variables you store it in.

As for the actual object that this handle represents, it takes up space wherever it is that the OpenGL implementation decides for it to. It can stick it in CPU memory, GPU memory, on your hard-disk, across the Internet, anywhere it wants. Though the last one is somewhat unlikely (though not impossible, as OpenGL was originally intended to be able to function across a network). It can even allocate memory in multiple such locations.

OpenGL allocates that memory, and it will delete it sometimes after you destroy the object.

This question is ultimately irrelevant to how you use the API.


it should be lived in each bind, after a new bind, the before will be broken.


as if opengl is for cpu, but only glsl is for gpu, dispect they are blended now.

It's not clear what you mean by either of these statements. For example, what does "lived in each bind" mean? And GLSL is part of OpenGL, so it's not clear what you're talking about here.

In the future, please take your time and try harder to use proper English. Also, multiple sentences would be very helpful.


I marked in the 2rd floor, I think it seems to overellaborate sometime. too much repeat bind, bind, despite its a good procedure to operate the gpu works. as if it were a script, not a language?

I don't know what kind of distinction you're trying to make between "script" and "language", but the use of the API is fine. For common OpenGL, at any rate. Yes, it involves a lot of bind calls. Generally speaking, you want to set up the storage for your buffers in one place, then set up how those buffers will be used in another. And if you're doing this for multiple buffers, then each buffer must be bound multiple times. Binding the next buffer unbinds the previous one (for the same slot). So once you've finished building storage for the buffers, the first buffer has long-since been unbound. So you have to bind it again.

If you don't like that API, you can try to restrict yourself to OpenGL 4.5, which allows you to skip the binding stuff (except when using the object) and talk directly to the objects. But that's not standard code yet, since it's a relatively new core OpenGL feature.

reader1
03-24-2015, 09:02 PM
sorry for incorrect format, I shall conrrect.
and that word is "despite", typo. embarracement.

reader1
03-24-2015, 09:06 PM
Like your first question on your shader program thread, you're asking good questions here. However, you need to understand each abstraction first: What's it used for? What's in it? How do you build one? Please do read up (in a decent OpenGL book, the OpenGL wiki, the OpenGL spec, modern OpenGL tutorial, or somewhere with solid OpenGL information) a bit more about what these objects you're asking about are. I think that will answer quite a few of the questions you're asking.

Each of these abstractions (VAO, VBO, shader, shader, program, etc.) is typically exposed to you as an object handle (usually a GLuint). This is not a pointer. It's also not a reference. It's more akin to a key in a dictionary (think std::map), though it could be an index into an array (think std::vector). The point is "to you" it's just an integer that is a handle. It means nothing to you, and you can do nothing with it but pass it to OpenGL. But the GL driver (or GPU) can use this to quickly lookup the state data for that OpenGL object abstraction (e.g. VAO, VBO, shader, shader program, etc.) for its internal processing.
r.
a handle should occupy a byte or more in mem, but it was told it has no space in mem. Alfonse siad in his 2 reply it was only a name. Does it has a space in cpu or gl mem?
if it were not, that means it exists or harnessed only in compiler?

hen, once you understand the abstractions, as to where each lives...

it should be lived in each bind, after a new bind, the before will be broken.

as if opengl is for cpu, but only glsl is for gpu, despite they are blended now.

reader1
03-24-2015, 09:33 PM
1]Typo,
2]it, which means doc or book. sorry for vague pronoun.

It can stick it in CPU memory, GPU memory, on your hard-disk, across the Internet, anywhere it wants. Though the last one is somewhat unlikely (though not impossible,

where on earth does it store in the opengl? you also said it was only a name, no occupation,

t's not clear what you mean by either of these statements. For example, what does "lived in each bind" mean? And GLSL is part of OpenGL, so it's not clear what you're talking about here.

In the future, please take your time and try harder to use proper English. Also, multiple sentences would be very helpful.

To ask a question and make other understand what you are meaning may be an art. sometimes, even using mother language may not express much clearly. However, a skillful one may grasp a tiny track to meke sense of the question.

what does "lived in each bind" mean? And GLSL is part of OpenGL,
say, glBindVertexArray statement or glBindBuffers will activity the vao or vbo at present until next glBind...

and now glsl blends into opengl. glsl is special language for gpu, but gl can be for cpu.
Can I make it sense?

reader1
03-24-2015, 09:59 PM
I don't know what kind of distinction you're trying to make between "script" and "language", but the use of the API is fine. For common OpenGL, at any rate. Yes, it involves a lot of bind calls. Generally speaking, you want to set up the storage for your buffers in one place, then set up how those buffers will be used in another. And if you're doing this for multiple buffers, then each buffer must be bound multiple times. Binding the next buffer unbinds the previous one (for the same slot). So once you've finished building storage for the buffers, the first buffer has long-since been unbound. So you have to bind it again.

If you don't like that API, you can try to restrict yourself to OpenGL 4.5, which allows you to skip the binding stuff (except when using the object) and talk directly to the objects. But that's not standard code yet, since it's a relatively new core OpenGL feature.
Needn't to say like or unlike, if you tend to use this language, you have to get use to it and comply with its roles. and make clear how or why or when it uses like that...

just like you said, Im not familiar with gpu structure. I don't know its controller, most docs said it has very weak controller, which can not match with that of cpu.
That may be why ceaselessly use bind, bind.
I originally thought, now that you know the address of buffers(vbo, vao etc.) why not transmit data from os mem(or say cpu mem) directly to that address in display card by opengl?
That will be more good if someone prompt me which will be depend on structure of gpu or something like that...

reader1
03-24-2015, 10:07 PM
try to restrict yourself to OpenGL 4.5, which allows you to skip the binding stuff (except when using the object) and talk directly to the objects. But that's not standard code yet, since it's a relatively new core OpenGL feature.
sound like the tgpu will change its structure largely.in hardware.

reader1
03-24-2015, 10:59 PM
The sample I put down seems not too good, the coding statements are repeating indeed.
I change their location and reduce several glBindBuffers, then compile and build, it works also well
the change is as follow,


glBindVertexArray(vaoHandle); //it seems to has nothing to do with its location
// Create and populate the buffer objects
GLuint vboHandles[2]; //declare two buffers.
glGenBuffers(2, vboHandles); //setup.
GLuint positionBufferHandle = vboHandles[0];
GLuint colorBufferHandle = vboHandles[1];

glBindBuffer(GL_ARRAY_BUFFER,positionBufferHandle) ;
glBufferData(GL_ARRAY_BUFFER,9 * sizeof(float),
positionData,GL_STATIC_DRAW);
glEnableVertexAttribArray(0); //enable vbo (0);
glVertexAttribPointer( 0, 3, GL_FLOAT, GL_FALSE, 0, (GLubyte *)NULL );///////

glBindBuffer(GL_ARRAY_BUFFER,colorBufferHandle);
glBufferData(GL_ARRAY_BUFFER,9 * sizeof(float),
colorData,GL_STATIC_DRAW);
glEnableVertexAttribArray(1);
glVertexAttribPointer( 1, 3, GL_FLOAT, GL_FALSE, 0, (GLubyte *)NULL );


This seems more compact and reasonable.

Alfonse Reinheart
03-24-2015, 11:49 PM
where on earth does it store in the opengl? you also said it was only a name, no occupation,

I have a name. But I also have a body. People can use my name to refer to my body, but that doesn't mean that my name is my body.

It's the same thing in OpenGL. When you create an OpenGL object, you get a name, a value that refers to a particular object. You don't get to look at this object or know where it is. But the OpenGL API knows how to get in contact with that object, so if you need to manipulate it or ask it questions, you give OpenGL the name.


say, glBindVertexArray statement or glBindBuffers will activity the vao or vbo at present until next glBind...

and now glsl blends into opengl. glsl is special language for gpu, but gl can be for cpu.

GLSL is not something that is separate from OpenGL. It's like saying that your legs blend into your body. Of course they do; they're part of your body.


Im not familiar with gpu structure

No, I said you're unfamiliar with OpenGL.

You have to understand that OpenGL is not the same thing as the GPU. OpenGL is an abstraction. The job of OpenGL is to actually hide what the GPU is doing, so that you don't have to care about specific details and such.

Learning the OpenGL API will not teach you "gpu structure". It can give you some idea of what is going on. But without many details.


This seems more compact and reasonable.

That all rather depends on what you're doing. For example, lets say I want to use the same buffer object in two different VAOs. There's no API reason why that's impossible, but the way your code is structured, you've put data creation and VAO operations in the same place. So if you have a new VAO that binds the old buffer and calls glVertexAttribPointer without doing glBufferData, it looks like an error.

Not everything is a simple tutorial example.

reader1
03-25-2015, 12:47 AM
That all rather depends on what you're doing. For example, lets say I want to use the same buffer object in two different VAOs. There's no API reason why that's impossible, but the way your code is structured, you've put data creation and VAO operations in the same place. So if you have a new VAO that binds the old buffer and calls glVertexAttribPointer without doing glBufferData, it looks like an error.

No, I will certainly not do like that. so does everyone. everyone always knows when new data entries, new glBufferData will be took place. and new bind, or there will be error.

OpenGL is not the same thing as the GPU
so it is. just like c and cpu etc. but if you know somethng about gpu, that will help you more to debug your program.

GLSL is not something that is separate from OpenGL
glsl is really apart from opengl at first, doc says like this as well.
glsl operates gpu, and opengl can cpu.
and at last they blend.

I have a name. But I also have a body. People can use my name to refer to my body, but that doesn't mean that my name is my body.

this means reference. ie. alias. but Dark Photon said it's not.
Its a handle. which is not like alias at all.

Dark Photon
03-25-2015, 06:52 AM
a handle should occupy a byte or more in mem, but it was told it has no space in mem. Alfonse siad in his 2 reply it was only a name. Does it has a space in cpu or gl mem? if it were not, that means it exists or harnessed only in compiler?

First, you need a good mental model to work with here. Conceptually, there are 3 memory spaces:


App CPU memory (CPU memory owned by your application),
GL driver CPU memory (CPU memory owned by the driver), and
GPU memory.


The latter two may or not be distinct (in general or for some GL objects) depending on GPU and driver architecture. But we'll ignore that for now. Assume a desktop GPU where these are likely to be separate.

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?



Then, once you understand the abstractions, as to where each lives...
it should be lived in each bind, after a new bind, the before will be broken.
I have no idea what you mean. That doesn't make any sense to me. I suspect language differences are getting in the way. Could you re-ask this question as a question using different terms?

reader1
03-25-2015, 07:44 AM
I have no idea what you mean. That doesn't make any sense to me. I suspect language differences are getting in the way. Could you re-ask this question as a question using different terms?
I thought you might ask how long is the period of a vbo activity?
I reply it should be the period from this bind vbo to next bind it.

and what terms shall I use to re-ask? and what question shall I re-ask?

reader1
03-25-2015, 08:15 AM
First, you need a good mental model to work with here. Conceptually, there are 3 memory spaces:

App CPU memory (CPU memory owned by your application),
GL driver CPU memory (CPU memory owned by the driver), and
GPU memory.
The latter two may or not be distinct (in general or for some GL objects) depending on GPU and driver architecture. But we'll ignore that for now. Assume a desktop GPU where these are likely to be separate.s?
I know this logical allocation which respond to physical memory. you say cpu mem, that must be that of memory on the mainboad, or say os mem. which is managed by cpu bus.
and gpu mem would be that on the display card. 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?
of cause this instructions is implemented by opengl api.
thank you very much for the patient and detail expression. I think we are in the same way.

reader1
03-25-2015, 08:38 AM
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
03-25-2015, 09:16 AM
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
03-25-2015, 11:29 AM
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:


This is my thinking,
shaderhandle = glCreateShader (); -->the return handle will store in opengl memory.(4byes)

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.


which has address information where the shader data will locate in gpu memory.

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


glShaderSource() will copy the data (which locate in opengl memory) into gpu memory.

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
03-25-2015, 06:17 PM
... you say cpu mem, that must be that of memory on the mainboad ... and gpu mem would be that on the display card.

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
03-25-2015, 07:51 PM
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.

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
03-25-2015, 08:01 PM
Yes, for the discrete GPU card case.
No problem!
but how does vao involve vbo is still vague.

Alfonse Reinheart
03-26-2015, 01:10 AM
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
03-26-2015, 07:46 AM
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
03-26-2015, 09:30 AM
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.

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
03-26-2015, 09:54 AM
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
03-26-2015, 10:03 AM
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
03-26-2015, 10:09 AM
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
03-26-2015, 02:25 PM
but how avo involves vbo is my question. how/

I could tell you to search for it on the OpenGL Wiki (searching for VAO (https://www.opengl.org/wiki_132/index.php?title=Special%3ASearch&profile=default&search=VAO&fulltext=Search) or VBO (https://www.opengl.org/wiki_132/index.php?title=Special%3ASearch&profile=default&search=VBO&fulltext=Search) would lead you to the correct pages), but you've already told us that you don't want to find information yourself.


But neirher CPU, no GPU has memory. they have only cache in the body.

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.


2] Mostly gPU is controlled by glsl.especially modern gou.

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 (http://en.cppreference.com/w/c/algorithm/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 (https://en.wikipedia.org/wiki/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 (https://www.opengl.org/wiki/Rendering_Pipeline_Overview), as defined by OpenGL and implemented on the GPU.

So the GPU is not controlled by GLSL.


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.


If you are referring to thisthread (https://www.opengl.org/discussion_boards/showthread.php/185815-Where-is-shading-statement), 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
03-26-2015, 08:04 PM
I could tell you to search for it on the OpenGL Wiki (searching for VAO (https://www.opengl.org/wiki_132/index.php?title=Special%3ASearch&profile=default&search=VAO&fulltext=Search) or VBO (https://www.opengl.org/wiki_132/index.php?title=Special%3ASearch&profile=default&search=VBO&fulltext=Search) would lead you to the correct pages), but you've already told us that you don't want to find information yourself.
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
03-26-2015, 09:08 PM
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.

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 (https://www.opengl.org/wiki/VAO) name/handle/alias/reference/whatever-you-want-to-cal-lit
* What it means to bind (https://www.opengl.org/wiki/OpenGL_Object#Object_Usage) a VAO
* What it means to generate a buffer object (https://www.opengl.org/wiki/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 (https://www.opengl.org/wiki/Buffer_Object#Creation) for a buffer object
* What it means to bind a buffer object to GL_ARRAY_BUFFER (https://www.opengl.org/wiki/Buffer_Object#General_use)
* What glVertexAttribPointer (https://www.opengl.org/wiki/VBO) 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.


So it is. ut why did you double my abridge writen on vertexarray and vertexattribarray...in another thread?

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.


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.

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
03-27-2015, 01:49 AM
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.
well, show me a real example, which has two vao, each includes two vbo.
this will be more clear than thousands of words.

reader1
03-27-2015, 02:31 AM
and explain,
the normal sequence should be,
1. 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
1. Generate Vertex Array Object
2. Bind Vertex Array Object
it still works well.
why?

Alfonse Reinheart
03-27-2015, 06:28 AM
and explain,
the normal sequence should be,
1. 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
1. Generate Vertex Array Object
2. Bind Vertex Array Object
it still works well.
why?

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
03-27-2015, 07:36 AM
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;
}

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
03-27-2015, 07:49 AM
Where is ptr? is it ptr2?

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


curious, what does it mean for you to put down such odd codes?
What relationship between the codes and the vao?

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.

reader1
03-27-2015, 08:02 AM
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.
Are you kidding?

reader1
03-27-2015, 08:48 AM
Do I need to remind you what is vao?

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
*
as if you are confusing the concept of vao and fShader. and shader...

Alfonse Reinheart
03-27-2015, 08:59 AM
Are you kidding?

No; I'm completely serious. Each line in those functions maps to the corresponding operation in your list. It's a direct, 1:1 mapping; it shouldn't be hard to work it out.

If you are unable to follow a simple analogy, I'll spell it out for you a bit more:



VertexArrayObject *boundVAO;
BufferObject *boundArrayBuffer;

void Standard()
{
VertexArrayObject *newVAO = new VertexArrayObject;
boundVAO = newVAO;
BufferObject *newBO = new BufferObject;
boundArrayBuffer = newBO;
}

void Modify()
{
BufferObject *newBO = new BufferObject;
boundArrayBuffer = newBO;
VertexArrayObject *newVAO = new VertexArrayObject;
boundVAO = newVAO;
}


Do you get it yet?


Do I need to remind you what is vao?

No, you don't. (https://www.opengl.org/wiki_132/index.php?title=Vertex_Specification&action=history)


as if you are confusing the concept of vao and fShader. and shader...

... what? I said nothing about shaders of any kind.