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

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 );


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);   ]]]/// [b]Do these two statements overelaborate?[/b]

////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); [b]//agine repeat![/b]
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);/[b]/ agai and again...[/b]
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?

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…

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 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”. 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.

How to use this multi -quote?

[QUOTE=reader1;1265066]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.[/QUOTE]

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.

[QUOTE=Dark Photon;1265092]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.[/QUOTE]
as if opengl is for cpu, but only glsl is for gpu, dispect they are blended now.

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?

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” is not a word.

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’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 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.

sorry for incorrect format, I shall conrrect.
and that word is “despite”, typo. embarracement.

[QUOTE=Dark Photon;1265092]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.[/QUOTE]
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.

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?

[QUOTE=Alfonse Reinheart;1265098]

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.[/QUOTE]
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…

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.

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.

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.

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.

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

[ol]
[li] App CPU memory (CPU memory owned by your application), [/li][li] GL driver CPU memory (CPU memory owned by the driver), and [/li][li] GPU memory. [/li][/ol]

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?

[quote]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. [/quote]
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 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?

[QUOTE=Dark Photon;1265123]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?[/QUOTE]
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.