• Advertisement
Sign in to follow this  

OpenGL question about sending ram->vram each frame

This topic is 1466 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

 

 

 

Share this post


Link to post
Share on other sites
Advertisement

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

 

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

 

 

- 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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

 

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

Share this post


Link to post
Share on other sites

 

 

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?

 

 

These days everything is done by shaders, even if you use the fixed function pipeline, The driver provides basic shaders that mimic the way the old fixed functions worked), glTranslate, glRotate etc modify a matrix on the CPU and the driver will pass it to its stock shaders if you issue a draw call without using your own shaders.

 

This is worth reading: http://classes.soe.ucsc.edu/cmps162/Spring12/s12/labnotes/shaders.html

Share this post


Link to post
Share on other sites

 

These days everything is done by shaders, even if you use the fixed function pipeline, The driver provides basic shaders that mimic the way the old fixed functions worked), glTranslate, glRotate etc modify a matrix on the CPU and the driver will pass it to its stock shaders if you issue a draw call without using your own shaders.

 

This is worth reading: http://classes.soe.ucsc.edu/cmps162/Spring12/s12/labnotes/shaders.html

 

 

well i can say that i am not learning it because i find all this

ugly and i just seem to not like it - though I must say some

game graphics achived by this are quite impressive - maybe i will start some topic on this becaouse Im curious for opinions 

if this opinion is only my own

Share this post


Link to post
Share on other sites


well i can say that i am not learning it because i find all this

ugly and i just seem to not like it - though I must say some

game graphics achived by this are quite impressive - maybe i will start some topic on this becaouse Im curious for opinions

if this opinion is only my own

 

Well, if you dont like shaders, no one is forcing you, you can still use the old opengl fixed pipeline if you wish.

 


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 )

 

I dont see the problem here. In opengl, you (usually) start a drawing a frame using something like glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT), (flags depend on what buffers you use, for example, the depth buffer is not needed in 2d, and you could use the flag GL_STENCIL_BUFFER_BIT to clear the stencil buffer if you're using it), then, you finish drawing by calling SwapBuffers(), which draw the backbuffer to the screen, assuming you're using double buffering., if not, i beleive you should call glFinish() (someone correct me if im wrong on that one).

 

Like many others have told you before, you usually try to avoid resending the same vertices to opengl every frame, since that's a huge performance hit. However, if you only need to draw a few vertices, that dosen't matter much imo. Also, about that copy in ram, once your done uploading the vbo to the gpu, it's ok to free the memory in ram, you probably (at least, in 99% of the cases) wont need it anymore.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Now

  • Advertisement
  • Similar Content

    • By reenigne
      For those that don't know me. I am the individual who's two videos are listed here under setup for https://wiki.libsdl.org/Tutorials
      I also run grhmedia.com where I host the projects and code for the tutorials I have online.
      Recently, I received a notice from youtube they will be implementing their new policy in protecting video content as of which I won't be monetized till I meat there required number of viewers and views each month.

      Frankly, I'm pretty sick of youtube. I put up a video and someone else learns from it and puts up another video and because of the way youtube does their placement they end up with more views.
      Even guys that clearly post false information such as one individual who said GLEW 2.0 was broken because he didn't know how to compile it. He in short didn't know how to modify the script he used because he didn't understand make files and how the requirements of the compiler and library changes needed some different flags.

      At the end of the month when they implement this I will take down the content and host on my own server purely and it will be a paid system and or patreon. 

      I get my videos may be a bit dry, I generally figure people are there to learn how to do something and I rather not waste their time. 
      I used to also help people for free even those coming from the other videos. That won't be the case any more. I used to just take anyone emails and work with them my email is posted on the site.

      I don't expect to get the required number of subscribers in that time or increased views. Even if I did well it wouldn't take care of each reoccurring month.
      I figure this is simpler and I don't plan on putting some sort of exorbitant fee for a monthly subscription or the like.
      I was thinking on the lines of a few dollars 1,2, and 3 and the larger subscription gets you assistance with the content in the tutorials if needed that month.
      Maybe another fee if it is related but not directly in the content. 
      The fees would serve to cut down on the number of people who ask for help and maybe encourage some of the people to actually pay attention to what is said rather than do their own thing. That actually turns out to be 90% of the issues. I spent 6 hours helping one individual last week I must have asked him 20 times did you do exactly like I said in the video even pointed directly to the section. When he finally sent me a copy of the what he entered I knew then and there he had not. I circled it and I pointed out that wasn't what I said to do in the video. I didn't tell him what was wrong and how I knew that way he would go back and actually follow what it said to do. He then reported it worked. Yea, no kidding following directions works. But hey isn't alone and well its part of the learning process.

      So the point of this isn't to be a gripe session. I'm just looking for a bit of feed back. Do you think the fees are unreasonable?
      Should I keep the youtube channel and do just the fees with patreon or do you think locking the content to my site and require a subscription is an idea.

      I'm just looking at the fact it is unrealistic to think youtube/google will actually get stuff right or that youtube viewers will actually bother to start looking for more accurate videos. 
    • By Balma Alparisi
      i got error 1282 in my code.
      sf::ContextSettings settings; settings.majorVersion = 4; settings.minorVersion = 5; settings.attributeFlags = settings.Core; sf::Window window; window.create(sf::VideoMode(1600, 900), "Texture Unit Rectangle", sf::Style::Close, settings); window.setActive(true); window.setVerticalSyncEnabled(true); glewInit(); GLuint shaderProgram = createShaderProgram("FX/Rectangle.vss", "FX/Rectangle.fss"); float vertex[] = { -0.5f,0.5f,0.0f, 0.0f,0.0f, -0.5f,-0.5f,0.0f, 0.0f,1.0f, 0.5f,0.5f,0.0f, 1.0f,0.0f, 0.5,-0.5f,0.0f, 1.0f,1.0f, }; GLuint indices[] = { 0,1,2, 1,2,3, }; GLuint vao; glGenVertexArrays(1, &vao); glBindVertexArray(vao); GLuint vbo; glGenBuffers(1, &vbo); glBindBuffer(GL_ARRAY_BUFFER, vbo); glBufferData(GL_ARRAY_BUFFER, sizeof(vertex), vertex, GL_STATIC_DRAW); GLuint ebo; glGenBuffers(1, &ebo); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ebo); glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices,GL_STATIC_DRAW); glVertexAttribPointer(0, 3, GL_FLOAT, false, sizeof(float) * 5, (void*)0); glEnableVertexAttribArray(0); glVertexAttribPointer(1, 2, GL_FLOAT, false, sizeof(float) * 5, (void*)(sizeof(float) * 3)); glEnableVertexAttribArray(1); GLuint texture[2]; glGenTextures(2, texture); glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D, texture[0]); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); sf::Image* imageOne = new sf::Image; bool isImageOneLoaded = imageOne->loadFromFile("Texture/container.jpg"); if (isImageOneLoaded) { glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, imageOne->getSize().x, imageOne->getSize().y, 0, GL_RGBA, GL_UNSIGNED_BYTE, imageOne->getPixelsPtr()); glGenerateMipmap(GL_TEXTURE_2D); } delete imageOne; glActiveTexture(GL_TEXTURE1); glBindTexture(GL_TEXTURE_2D, texture[1]); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); sf::Image* imageTwo = new sf::Image; bool isImageTwoLoaded = imageTwo->loadFromFile("Texture/awesomeface.png"); if (isImageTwoLoaded) { glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, imageTwo->getSize().x, imageTwo->getSize().y, 0, GL_RGBA, GL_UNSIGNED_BYTE, imageTwo->getPixelsPtr()); glGenerateMipmap(GL_TEXTURE_2D); } delete imageTwo; glUniform1i(glGetUniformLocation(shaderProgram, "inTextureOne"), 0); glUniform1i(glGetUniformLocation(shaderProgram, "inTextureTwo"), 1); GLenum error = glGetError(); std::cout << error << std::endl; sf::Event event; bool isRunning = true; while (isRunning) { while (window.pollEvent(event)) { if (event.type == event.Closed) { isRunning = false; } } glClear(GL_COLOR_BUFFER_BIT); if (isImageOneLoaded && isImageTwoLoaded) { glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D, texture[0]); glActiveTexture(GL_TEXTURE1); glBindTexture(GL_TEXTURE_2D, texture[1]); glUseProgram(shaderProgram); } glBindVertexArray(vao); glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_INT, nullptr); glBindVertexArray(0); window.display(); } glDeleteVertexArrays(1, &vao); glDeleteBuffers(1, &vbo); glDeleteBuffers(1, &ebo); glDeleteProgram(shaderProgram); glDeleteTextures(2,texture); return 0; } and this is the vertex shader
      #version 450 core layout(location=0) in vec3 inPos; layout(location=1) in vec2 inTexCoord; out vec2 TexCoord; void main() { gl_Position=vec4(inPos,1.0); TexCoord=inTexCoord; } and the fragment shader
      #version 450 core in vec2 TexCoord; uniform sampler2D inTextureOne; uniform sampler2D inTextureTwo; out vec4 FragmentColor; void main() { FragmentColor=mix(texture(inTextureOne,TexCoord),texture(inTextureTwo,TexCoord),0.2); } I was expecting awesomeface.png on top of container.jpg

    • By khawk
      We've just released all of the source code for the NeHe OpenGL lessons on our Github page at https://github.com/gamedev-net/nehe-opengl. code - 43 total platforms, configurations, and languages are included.
      Now operated by GameDev.net, NeHe is located at http://nehe.gamedev.net where it has been a valuable resource for developers wanting to learn OpenGL and graphics programming.

      View full story
    • By TheChubu
      The Khronos™ Group, an open consortium of leading hardware and software companies, announces from the SIGGRAPH 2017 Conference the immediate public availability of the OpenGL® 4.6 specification. OpenGL 4.6 integrates the functionality of numerous ARB and EXT extensions created by Khronos members AMD, Intel, and NVIDIA into core, including the capability to ingest SPIR-V™ shaders.
      SPIR-V is a Khronos-defined standard intermediate language for parallel compute and graphics, which enables content creators to simplify their shader authoring and management pipelines while providing significant source shading language flexibility. OpenGL 4.6 adds support for ingesting SPIR-V shaders to the core specification, guaranteeing that SPIR-V shaders will be widely supported by OpenGL implementations.
      OpenGL 4.6 adds the functionality of these ARB extensions to OpenGL’s core specification:
      GL_ARB_gl_spirv and GL_ARB_spirv_extensions to standardize SPIR-V support for OpenGL GL_ARB_indirect_parameters and GL_ARB_shader_draw_parameters for reducing the CPU overhead associated with rendering batches of geometry GL_ARB_pipeline_statistics_query and GL_ARB_transform_feedback_overflow_querystandardize OpenGL support for features available in Direct3D GL_ARB_texture_filter_anisotropic (based on GL_EXT_texture_filter_anisotropic) brings previously IP encumbered functionality into OpenGL to improve the visual quality of textured scenes GL_ARB_polygon_offset_clamp (based on GL_EXT_polygon_offset_clamp) suppresses a common visual artifact known as a “light leak” associated with rendering shadows GL_ARB_shader_atomic_counter_ops and GL_ARB_shader_group_vote add shader intrinsics supported by all desktop vendors to improve functionality and performance GL_KHR_no_error reduces driver overhead by allowing the application to indicate that it expects error-free operation so errors need not be generated In addition to the above features being added to OpenGL 4.6, the following are being released as extensions:
      GL_KHR_parallel_shader_compile allows applications to launch multiple shader compile threads to improve shader compile throughput WGL_ARB_create_context_no_error and GXL_ARB_create_context_no_error allow no error contexts to be created with WGL or GLX that support the GL_KHR_no_error extension “I’m proud to announce OpenGL 4.6 as the most feature-rich version of OpenGL yet. We've brought together the most popular, widely-supported extensions into a new core specification to give OpenGL developers and end users an improved baseline feature set. This includes resolving previous intellectual property roadblocks to bringing anisotropic texture filtering and polygon offset clamping into the core specification to enable widespread implementation and usage,” said Piers Daniell, chair of the OpenGL Working Group at Khronos. “The OpenGL working group will continue to respond to market needs and work with GPU vendors to ensure OpenGL remains a viable and evolving graphics API for all its customers and users across many vital industries.“
      The OpenGL 4.6 specification can be found at https://khronos.org/registry/OpenGL/index_gl.php. The GLSL to SPIR-V compiler glslang has been updated with GLSL 4.60 support, and can be found at https://github.com/KhronosGroup/glslang.
      Sophisticated graphics applications will also benefit from a set of newly released extensions for both OpenGL and OpenGL ES to enable interoperability with Vulkan and Direct3D. These extensions are named:
      GL_EXT_memory_object GL_EXT_memory_object_fd GL_EXT_memory_object_win32 GL_EXT_semaphore GL_EXT_semaphore_fd GL_EXT_semaphore_win32 GL_EXT_win32_keyed_mutex They can be found at: https://khronos.org/registry/OpenGL/index_gl.php
      Industry Support for OpenGL 4.6
      “With OpenGL 4.6 our customers have an improved set of core features available on our full range of OpenGL 4.x capable GPUs. These features provide improved rendering quality, performance and functionality. As the graphics industry’s most popular API, we fully support OpenGL and will continue to work closely with the Khronos Group on the development of new OpenGL specifications and extensions for our customers. NVIDIA has released beta OpenGL 4.6 drivers today at https://developer.nvidia.com/opengl-driver so developers can use these new features right away,” said Bob Pette, vice president, Professional Graphics at NVIDIA.
      "OpenGL 4.6 will be the first OpenGL release where conformant open source implementations based on the Mesa project will be deliverable in a reasonable timeframe after release. The open sourcing of the OpenGL conformance test suite and ongoing work between Khronos and X.org will also allow for non-vendor led open source implementations to achieve conformance in the near future," said David Airlie, senior principal engineer at Red Hat, and developer on Mesa/X.org projects.

      View full story
    • By _OskaR
      Hi,
      I have an OpenGL application but without possibility to wite own shaders.
      I need to perform small VS modification - is possible to do it in an alternative way? Do we have apps or driver modifictions which will catch the shader sent to GPU and override it?
  • Advertisement