Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


question about sending ram->vram each frame


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
22 replies to this topic

#1 fir   Members   -  Reputation: -456

Like
0Likes
Like

Posted 13 January 2014 - 05:39 AM

I am only slightly experienced in opengl (i am mostly doing

2d on blitter stuff) and i would like to clear some things with it,

maybe some will help me to clarify..

 

As i understand you need to transfer (ram -> vram upload)

 two kinds of data :

- geometry data 

- texture data

 

as i understand texture data you only upload mostly once (at app startup) not each frame (except if you got not sufficient vram then you could destroy 

some upload some other, it is switch texture set for example between 

game chapters,.. but in general you do not do it on perframe basis) [is this correct?]

- also if you need tochange texture data you usually change it on vram side

by shaders.. [is this correct?]

 

more confused i am with dealing with geometry data :

 

here i am not sure but it seem to me that geometry data is in 

generall uploaded on perframe basis (it is you send heavy thousands of triangles each frame with cpu to gpu side - then after every frame 

the vram set of it is destroyed/cleared (which opengl call clears it?

i do not know the thing here..) for example even if you have vertex

array you need to send it (ram->vram) each frame

is this correct or not? are there some mechanism that prevents 

the uploaed geometry arrays on vram side and allow only for

manipulating them there? (for example heavy mesh is being uploaded to 

vram and it stays there for hundreds of frames you can only send some

parameters like modifile position matrixes for each mesh nodes not whole

mesh data? could someone clear the thing?

 

 

 



Sponsor:

#2 3TATUK2   Members   -  Reputation: 730

Like
3Likes
Like

Posted 13 January 2014 - 05:54 AM

You should not be resending identical data. Create a VBO once and reuse it.

 

Yes, you use translation/rotation matrices.

 

You can even interpolate animation with a single mesh plus several skeletal keyframe matrices.


Edited by 3TATUK2, 13 January 2014 - 05:55 AM.


#3 fir   Members   -  Reputation: -456

Like
-4Likes
Like

Posted 13 January 2014 - 12:17 PM

No answers? this seem to be fundamental and important topics, important to get answer..



#4 richardurich   Members   -  Reputation: 1187

Like
1Likes
Like

Posted 13 January 2014 - 02:46 PM

You already got the answer. You pass vertices once. As a general rule, they don't ever change.

 
 
If you moved your vertices, they'd accumulate FP math errors and your model would stop being the model you think it is.
 

You also got an example of how you avoid resending data using matrices in the answer. You were even told to look up more information by looking into skeletal keyframe animation. While 3TATUK2 obviously dumbed the animation explanation down, you should know enough from the explanation to effectively google about animation.

 

To help understand animation better, maybe you can think of a simpler animation where you pass 2 vertices into the vertex shader and a time variable. You use the time variable to do a linear interpolation on the two vertices to calculate the vertex you actually want to work on in the shader. Note that this is not matrices, but hopefully it gets you thinking about how you can deform a vertex in the shader to work on a calculated vertex instead of a directly specified one.


Edited by richardurich, 13 January 2014 - 02:47 PM.


#5 laztrezort   Members   -  Reputation: 972

Like
1Likes
Like

Posted 13 January 2014 - 03:33 PM

Technically, most of the answers to your question depend on what you are doing - but for efficiency, it's better to limit transfering from client to server (or vice versa) as much as possible.

 

Really, I suggest going through some tutorials, look up "modern OpenGL tutorials" or similar.  Make sure the tutorials are "modern" or at least version 3 or later.  For example, this one http://www.opengl-tutorial.org/ seems good, I believe it was one of the tutorials I skimmed through it when moving from XNA to OpenGL a year or two ago and found it helpful.

 

After you get the basics, going through the OpengGL wiki is helpful on the nuts & bolts aspects of OpenGL.



#6 fir   Members   -  Reputation: -456

Like
-4Likes
Like

Posted 13 January 2014 - 03:57 PM

Technically, most of the answers to your question depend on what you are doing - but for efficiency, it's better to limit transfering from client to server (or vice versa) as much as possible.

 

Really, I suggest going through some tutorials, look up "modern OpenGL tutorials" or similar.  Make sure the tutorials are "modern" or at least version 3 or later.  For example, this one http://www.opengl-tutorial.org/ seems good, I believe it was one of the tutorials I skimmed through it when moving from XNA to OpenGL a year or two ago and found it helpful.

 

After you get the basics, going through the OpengGL wiki is helpful on the nuts & bolts aspects of OpenGL.

maybe it may seem strange but i got not to much time for learning opengl - i just need some answers like here

(Im doing 2d blitter graphics for over a year not touching

ogl)

 

cannot them be just answered, they are quite simple?



#7 fir   Members   -  Reputation: -456

Like
-4Likes
Like

Posted 13 January 2014 - 04:03 PM

Technically, most of the answers to your question depend on what you are doing - but for efficiency, it's better to limit transfering from client to server (or vice versa) as much as possible.

 

Really, I suggest going through some tutorials, look up "modern OpenGL tutorials" or similar.  Make sure the tutorials are "modern" or at least version 3 or later.  For example, this one http://www.opengl-tutorial.org/ seems good, I believe it was one of the tutorials I skimmed through it when moving from XNA to OpenGL a year or two ago and found it helpful.

 

After you get the basics, going through the OpengGL wiki is helpful on the nuts & bolts aspects of OpenGL.

 

I was only using some basic opengl, when i was drawing 

some basic opengl i sent a full vertex array each frame..

so what with that .. there is a way of sending all meshes 

at app startup and then sending only position matrices each frame?

 

as to this post of 3tatuk2 it was zero helpfull (belive me

i know what im saying ;\)

 

there is also subquestion of deleting the geometry data

- if i upload a large vertex geometry in the frame and it resides in vram then it seem that before sendoing it next frame some api call deletes the prevoius in the vram.. is this true? what api call this is?

 

as to moving the vertices i do not want to move the vertices by updating the vertex array but just use glRotate glTranslate but then it is again whole vertex array sending (uploading)... is this correct way of writing programs or this is bad way at all?


Edited by fir, 13 January 2014 - 04:24 PM.


#8 BitMaster   Crossbones+   -  Reputation: 4437

Like
1Likes
Like

Posted 13 January 2014 - 04:09 PM

as to this post of 3tatuk2 it was zero helpfull (belive me
i know what im saying ;\)


No, you don't. Creating a VBO and putting the vertex/index data in there (just like 3TATUK2 said) is the exact way you avoid uploading the identical data to the graphics card every frame.

The first Google result for 'VBO' is even this Wikipedia page which, while not perfect, gives a very decent introduction to the concept.

#9 richardurich   Members   -  Reputation: 1187

Like
1Likes
Like

Posted 13 January 2014 - 04:28 PM

If someone tells you how to do something (transfer data only once to GPU using OpenGL in this case), you can safely assume it is possible. You seem upset that nobody explicitly said it is possible, but I'm not sure what other conclusion could be reached. It is the reason I did not reply to the original post. I felt I could add nothing of value beyond what 3tatuk2 said.

 

You can load your textures and vertices (meshes, whatever) at application startup. You can also do it when loading a level (that's what all those loading screens in AAA games are doing). You can also do it in between every frame. You can even reload every model, then call a single draw of a single triangle, then reload every model again. Performance will definitely vary with each of those options.

 

When you are programming, the computer does whatever you tell it to do.



#10 empirical2   Members   -  Reputation: 567

Like
1Likes
Like

Posted 13 January 2014 - 04:57 PM

Ok, Ill try. Fir;

 

>> there is a way of sending all meshes  at app startup and then sending only position matrices each frame?<<
 
Yes
 
>>if i upload a large vertex geometry in the frame and it resides in vram then it seem that before sendoing it next frame some api call deletes the prevoius in the vram.. is this true? what api call this is?<<
 
Immediate mode?
 
>>as to moving the vertices i do not want to move the vertices by updating the vertex array but just use glRotate glTranslate but then it is again whole vertex array sending (uploading)..<<
 

 

You can use glRotate/glTranslate without uploading the whole array using VBOs as everyone has been telling you.

 

>>. is this correct way of writing programs or this is bad way at all?<<

 

I believe its deprecated and you should use your own matrices. However, it does still work with glTranslate etc. 



#11 SimonForsman   Crossbones+   -  Reputation: 6323

Like
1Likes
Like

Posted 13 January 2014 - 06:06 PM

What you want is to do is use Vertex buffer objects (VBO) They store all your mesh data on the GPU until you explicitly destroy them and then do skeletal animation using the vertex shaders(GPU skinning) that way you only have to send transformation matrices for the bones each frame in order to animate the mesh.


I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#12 BitMaster   Crossbones+   -  Reputation: 4437

Like
1Likes
Like

Posted 14 January 2014 - 02:37 AM

there is also subquestion of deleting the geometry data
- if i upload a large vertex geometry in the frame and it resides in vram then it seem that before sendoing it next frame some api call deletes the prevoius in the vram.. is this true? what api call this is?

If you do not store your vertex attributes in a VBO, the whole data will be moved from the system to the graphics card on every glDraw* call. After everything ordered in the glDraw* call has been rendered, the memory containing the data is immediately freed. The concept of 'frame' does not play into it and it's not really something that makes much sense in the context of modern OpenGL.
 

as to moving the vertices i do not want to move the vertices by updating the vertex array but just use glRotate glTranslate but then it is again whole vertex array sending (uploading)... is this correct way of writing programs or this is bad way at all?

As said repeatedly, static data which is rendered repeated is usually placed in a VBO. Using glRotatef, glTranslatef is no longer used in modern programs. That whole part of the API has been deprecated for good reasons. And while it's unlikely that your programs will stop working (at least on AMD or NVIDIA card) for the foreseeable future, you are artificially locking yourself out of new features, might end up on code paths that are less optimal than using the modern API and you are causing yourself more pain and inconvenience in the future (because the modern API has a bit more initial boilerplate code you need but is far simpler once that initial investment is done).

#13 fir   Members   -  Reputation: -456

Like
0Likes
Like

Posted 14 January 2014 - 05:00 AM

What you want is to do is use Vertex buffer objects (VBO) They store all your mesh data on the GPU until you explicitly destroy them and then do skeletal animation using the vertex shaders(GPU skinning) that way you only have to send transformation matrices for the bones each frame in order to animate the mesh.

allright, this means that this vertex array way is deprecated?



#14 fir   Members   -  Reputation: -456

Like
0Likes
Like

Posted 14 January 2014 - 05:14 AM

 

there is also subquestion of deleting the geometry data
- if i upload a large vertex geometry in the frame and it resides in vram then it seem that before sendoing it next frame some api call deletes the prevoius in the vram.. is this true? what api call this is?

If you do not store your vertex attributes in a VBO, the whole data will be moved from the system to the graphics card on every glDraw* call. After everything ordered in the glDraw* call has been rendered, the memory containing the data is immediately freed. The concept of 'frame' does not play into it and it's not really something that makes much sense in the context of modern OpenGL.
 

as to moving the vertices i do not want to move the vertices by updating the vertex array but just use glRotate glTranslate but then it is again whole vertex array sending (uploading)... is this correct way of writing programs or this is bad way at all?

As said repeatedly, static data which is rendered repeated is usually placed in a VBO. Using glRotatef, glTranslatef is no longer used in modern programs. That whole part of the API has been deprecated for good reasons. And while it's unlikely that your programs will stop working (at least on AMD or NVIDIA card) for the foreseeable future, you are artificially locking yourself out of new features, might end up on code paths that are less optimal than using the modern API and you are causing yourself more pain and inconvenience in the future (because the modern API has a bit more initial boilerplate code you need but is far simpler once that initial investment is done).

 

 

 

What you want is to do is use Vertex buffer objects (VBO) They store all your mesh data on the GPU until you explicitly destroy them and then do skeletal animation using the vertex shaders(GPU skinning) that way you only have to send transformation matrices for the bones each frame in order to animate the mesh.

 

 

allright this is usefull - i understand that there are two modes one does vram geometry clearing other preserves it

 

- though as to clearing i do not understand when it clears is it immediate, when some source triangle is just sent thru rendering its source data is freed immediate  or this is on some frame basis? (i understand you sy this is more immediate but i do not see it clearly, previously i suspected it was more like glFlush end of the frame)

 

- also i do not know how to sent the parameters to the whole big set of geometry data residing in vram - say it is by shaders, istn it very unhandy ? if you have scene that

contains a thousand of meshes need a thousand of parameters (position etc).. so

there is a thousand case switch in the shader which is reaching thousand times 

to cpu RAM memory to fetch this coordinates?



#15 fir   Members   -  Reputation: -456

Like
-2Likes
Like

Posted 14 January 2014 - 05:18 AM

If someone tells you how to do something (transfer data only once to GPU using OpenGL in this case), you can safely assume it is possible. You seem upset that nobody explicitly said it is possible, but I'm not sure what other conclusion could be reached. It is the reason I did not reply to the original post. I felt I could add nothing of value beyond what 3tatuk2 said.

 

You can load your textures and vertices (meshes, whatever) at application startup. You can also do it when loading a level (that's what all those loading screens in AAA games are doing). You can also do it in between every frame. You can even reload every model, then call a single draw of a single triangle, then reload every model again. Performance will definitely vary with each of those options.

 

When you are programming, the computer does whatever you tell it to do.

 

those first pseudo answer gioved nothing valuable to me.. i need to get and talk about some explanations and deeper topics not 10 seconds answers which i found more bad than helpfull so thay had subsero value for me personally, really

 

(as i said iam searchng for answer and some discussion, sadly get not to much time to go further now into opengl, maybe next year - but the later answers shows to be quite ok, tnx for later answers, now i feel i get it right - the  details then i can check in the future ;o)


Edited by fir, 14 January 2014 - 06:31 AM.


#16 richardurich   Members   -  Reputation: 1187

Like
1Likes
Like

Posted 14 January 2014 - 06:47 AM

allright this is usefull - i understand that there are two modes one does vram geometry clearing other preserves it

 

Sort of. Vertex Arrays (not to be confused with Vertex Array Objects) are client-side, so the video driver has to reload the data on every call because you could have changed the contents since it is client-side.

 

 

- though as to clearing i do not understand when it clears is it immediate, when some source triangle is just sent thru rendering its source data is freed immediate  or this is on some frame basis? (i understand you sy this is more immediate but i do not see it clearly, previously i suspected it was more like glFlush end of the frame)

 

 

If you're talking about client-side vertex arrays, nothing gets cleared and your client-side memory does not get freed. He was probably talking about the video card's cache of your data being useless once the call finishes. Your client-side copy will have the same values for any attributes not modified by the glDraw*, and undefined values for any attributes modified.

 

- also i do not know how to sent the parameters to the whole big set of geometry data residing in vram - say it is by shaders, istn it very unhandy ? if you have scene that

contains a thousand of meshes need a thousand of parameters (position etc).. so

there is a thousand case switch in the shader which is reaching thousand times 
to cpu RAM memory to fetch this coordinates?

 

 

 

Shaders are the computational units of a GPU. Providing data to GPU computational units is quite handy, just like it's handy to provide data from system RAM to the CPU.

 

You can have thousands of meshes. You can use switch in the shaders if you want, but they're not going to fetch data from CPU RAM. If you want something from CPU RAM available to the shaders, you need to pass it over.

 

You'll specify how many vertices are going to be drawn (1 mesh, only part of a mesh, 10 meshes, whatever you choose), and the video card splits the vertices up and feeds them to the shaders. The video card might have thousands of shader units, so this will all be done in parallel.


Edited by richardurich, 14 January 2014 - 06:50 AM.


#17 fir   Members   -  Reputation: -456

Like
0Likes
Like

Posted 14 January 2014 - 07:47 AM

 

 

- though as to clearing i do not understand when it clears is it immediate, when some source triangle is just sent thru rendering its source data is freed immediate  or this is on some frame basis? (i understand you sy this is more immediate but i do not see it clearly, previously i suspected it was more like glFlush end of the frame)

 

 

If you're talking about client-side vertex arrays, nothing gets cleared and your client-side memory does not get freed. He was probably talking about the video card's cache of your data being useless once the call finishes. Your client-side copy will have the same values for any attributes not modified by the glDraw*, and undefined values for any attributes modified.

 

 

no,no 

 

say i have 1MB (ram) vertex array containing some mesh (bunny or something)

 

i command it to draw on screen (i was using glDrawElements)

 

so this is being uploaded to vram, so now i got two copies of

it 1MB in ram and 1 MB in vram

 

then it is drawed, (I was never thinking on it to much yet but 

i see in my code that this procedure is repeated every frame

so it is near to obvoious that this vram copy is probably cleared 

each frame,

 

(this should be I think about the whole geometry data set send

this way in each frame - it must be cleared if this is constantly uploaded)

 

(*) [by this i mean the vram copy of this source geometry]

 

BitMaster said (confirmed) (that was helpful) this is cleared (*)-  i was suspecting that this is cleared, though i never heard when  is the moment where it is cleared (I suspected that maybe  this is at the end of the frame, I dont know glSwapBuffers of glflush something like that)

BitMaster said (if i understood) that it is cleared immediately

(like a stream) when gpu consumes it - this is also an option i think .. i dont know

 

You something about cache, (you probably call the thing i call here as a vram mesh copy as a cache) and i was also incidentally begin thinking now if there is maybe some cache mechanisms involved (because when i sent every frame a 1MB bunny vertex array which is not changing , it would be maybe theoretically possible that glDrawElements could reuse previous uploaded copy (you could probably sent a hint, that this is was

not changed - but this is probably not involved, as i understand

the mechanism called VBO is used here instead

 

so finally now some things seem cleared for me here, though 

maybe not all and if someone could share some more info yet

thanx for that 


Edited by fir, 14 January 2014 - 07:49 AM.


#18 BitMaster   Crossbones+   -  Reputation: 4437

Like
1Likes
Like

Posted 14 January 2014 - 08:02 AM

so this is being uploaded to vram, so now i got two copies of
it 1MB in ram and 1 MB in vram

Actually you have three copies. When you call glDraw* the driver copies the data you gave it into system memory that belongs to the driver and schedules an upload to video memory. Then glDraw* returns and you are free to do whatever you want with the memory you gave to glDraw*.
Once the driver has finished uploading the data to the video card it can schedule rendering of the data. At this point the system memory copy can also be freed.
Once rendering of the data has happened the data in video memory is freed.

then it is drawed, (I was never thinking on it to much yet but 
i see in my code that this procedure is repeated every frame
so it is near to obvoious that this vram copy is probably cleared 
each frame,

Again, talking about 'frames' in the concept of modern OpenGL is pretty pointless. Things can be rendered to various framebuffers, the framebuffers can be used to render something else and some point down the line something is displayed to the user (or maybe not even that).
If you render the same mesh N times without the help of an VBO the same data will be uploaded N times to video memory, regardless of where you place your artificial frame points.

You something about cache, (you probably call the thing i call here as a vram mesh copy as a cache) and i was also incidentally begin thinking now if there is maybe some cache mechanisms involved (because when i sent every frame a 1MB bunny vertex array which is not changing , it would be maybe theoretically possible that glDrawElements could reuse previous uploaded copy (you could probably sent a hint, that this is was
not changed - but this is probably not involved, as i understand
the mechanism called VBO is used here instead

When you pass data without the aid of an VBO to a glDraw* call you implicitly tell the driver there is no point doing anything interesting with the data. It's throwaway data. If it's data worth keeping around the user would have put it into an VBO.

#19 richardurich   Members   -  Reputation: 1187

Like
0Likes
Like

Posted 14 January 2014 - 09:22 AM

(this should be I think about the whole geometry data set send

this way in each frame - it must be cleared if this is constantly uploaded)

 

(*) [by this i mean the vram copy of this source geometry]

 

BitMaster said (confirmed) (that was helpful) this is cleared (*)-  i was suspecting that this is cleared, though i never heard when  is the moment where it is cleared (I suspected that maybe  this is at the end of the frame, I dont know glSwapBuffers of glflush something like that)

BitMaster said (if i understood) that it is cleared immediately

(like a stream) when gpu consumes it - this is also an option i think .. i dont know

 

You something about cache, (you probably call the thing i call here as a vram mesh copy as a cache) and i was also incidentally begin thinking now if there is maybe some cache mechanisms involved (because when i sent every frame a 1MB bunny vertex array which is not changing , it would be maybe theoretically possible that glDrawElements could reuse previous uploaded copy (you could probably sent a hint, that this is was

not changed - but this is probably not involved, as i understand

the mechanism called VBO is used here instead

 

 

If you mean the video driver's copy (or copies) of the data is discarded when you say cleared, that's right. It never needs to be cleared though (memset to zero, zeromemory'd, calloc'd, etc.). I used the word cache to convey to you that the video driver recognizes the call as client-side memory and anything the driver uses will just be a cached copy. Think of it as cache marked as invalid for every other command. It was just a different way to look at the same thing in the hopes it made more sense to you.

 

Some vendors did provide functions to help avoid copying the memory around extra times. For example, Apple had GL_APPLE_vertex_array_range that let you promise not to touch the memory except as explained in the extension.



#20 fir   Members   -  Reputation: -456

Like
0Likes
Like

Posted 14 January 2014 - 09:48 AM

 

then it is drawed, (I was never thinking on it to much yet but 
i see in my code that this procedure is repeated every frame
so it is near to obvoious that this vram copy is probably cleared 
each frame,

Again, talking about 'frames' in the concept of modern OpenGL is pretty pointless. Things can be rendered to various framebuffers, the framebuffers can be used to render something else and some point down the line something is displayed to the user (or maybe not even that).
If you render the same mesh N times without the help of an VBO the same data will be uploaded N times to video memory, regardless of where you place your artificial frame points.
 

well, ok 

though i am not accustomed to using non frame terminology,

physically you render frames 

if you do not use frames concept you mean something like

stream of images that could add to sum up images without any boundaries that it is finished... weird

 

for example you send buny than little house than some rocket

(to make of an image of bunny house and rocket, imo frame

is needed to say when you got result ready to draw and when

not yet 

 

(so i just doubt if it possible not to use frame concept in ogl, one need to know when frame is ready - and also need some 

notion of beggining the frame (need to clear it sometimes) - but do not matter )


Edited by fir, 14 January 2014 - 10:23 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS