Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Jul 2009
Offline Last Active Today, 01:05 PM

#5064985 Programming in OpenGL 4 with a netbook, it is posible?

Posted by on 26 May 2013 - 09:01 AM

At least under linux I can use GLSL 1.0 on my Atom N550 netbook (which has said GM3150). Performance is obviously questionable at best.

Wow! That's a miraculous achievement of GM3150. smile.png

Let's remember, GL2.0 requires GLSL 1.1 (or tu be more precise 1.10.xx).

GLSL 1.0 is a predecessor of GLSL exposed in the time of GL1.4 to announce arrival of new era. The interface to shaders is not the same as in GLSL 1.1 and other successors. That's what I meant when said ancient  interface.

#5064958 Programming in OpenGL 4 with a netbook, it is posible?

Posted by on 26 May 2013 - 06:07 AM

Hold on. Let OP say what graphics card he's got.

If it is GMA3150 (like in my netbook), then he should say farewell to shaders. It is hard to say that GMA3150 supports even GL1.5, and it is light-years away from the GL 2.0. There is only 2 fragmet shader units, and vertex shader is supported only in software (for D3D). There is an interface to some prehistoric version of shaders, but there is no support even for GLSL 1.x.

#5056592 OpenGL Erroneous Context Version

Posted by on 25 April 2013 - 02:27 AM

Why are you creating a dummy window?

That should be done only if you need multisampling without FBO, in order to find appropriate pixel format.

In all other cases, you should do the following:


1. Make a new (visible) window and set appropriate pixel format
2. Create a dummy context with wglCreateContext
3. Set the dummy context to be current
4. Create a new (GL 3.0+) context with wglCreateContextAttribsARB having the desired properties
5: Set the new context to be current
6: Delete dummy context

7: Load extensions using the new context

#5035560 How do I determine the maximum VBO size?

Posted by on 22 February 2013 - 03:38 PM

There are several ways to get information about memory allocation through the API. NVX_gpu_memory_info and ATI_meminfo are some of the extensions for that.

I tried to summarize main aspects of those extensions in OpenGL Insights, Chapter 38, pg.535-540.


There is a limit in size of objects in graphics card memory. It depends on graphics card memory size, driver policy, and probably architecture. Different vendors also expose different policies. NV, for example, won't draw objects that cannot fit into the dedicated graphics memory, while AMD allows drawing directly from the shared system memory. This shouldn't be accepted as absolute truth, but that's just the behavior of drivers and cards I had tested.


In any case, splitting gigantic VBOs into smaller chunks enables more efficient memory management. At the cost of reducing performance, the sum of dedicated and shared memory can be used for storing graphics objects.

#5032010 a brief question

Posted by on 13 February 2013 - 03:17 PM

Nope! OpenGL does not handle either input or audio.

#5015710 Most efficient way to batch drawings

Posted by on 30 December 2012 - 04:43 AM

| measuring it with gDEBugger, setting SwapBuffer as end-of-frame. With the profiling of Visual Studio, I can see clearly that SwapBuffers takes the 50% of the CPU in a single frame.


Well, I don't know how gDEBugger measures execution time, but I have to draw your attention to the following facts:

1. All issued GL commands execute on both CPU and GPU.

2. CPU execution time is usually very short (of course it depends on a command), commands are set in a command queue and the control is returned to the CPU.

3. SwapBuffers, as its name implies, exchanges the front and back buffers. In order to do that, it flushes command queue and waits until the drawing is finished. It is probably dependent on the implementation, but on my laptop with Windows Vista, it is a blocking function. Take a look at the attached picture.



Blue lines represent CPU time, while red ones represent GPU time. Although you could say SwapBuffers consumes 78% of the frame time, it is simple not the truth. The answer is in the blue line in the window "Frame". GPU takes about 13ms to render the frame, although CPU is utilized only 0.67ms. That's what I talked about.


4. Frame-rate can be only 120 (rarely), 60, 30, 15, etc. if vsync is on. What you have posted is an effective frame-rate. So, it is better to use time of execution instead of FPS.


5. Having effective frame-rate greater than 120 induce performance state changing, since GPU is not utilized enough. It is very hard to profile application in such circumstances. That's why I proposed a performance state tracking alongside with profiling (take a look at OpenGL Insights, pg.527-534.). 

#5015427 Most efficient way to batch drawings

Posted by on 29 December 2012 - 08:46 AM

For some reason, VBO decrease the performances and with this, SwapBuffer takes a lot of CPU. However all this methods are CPU-limited, because the GPU isn't totally used. Much of the CPU is drawined by memcpy and SwapBuffer.


EDIT: I tried the same tests with the same software without edits on another computer that handle a Intel HD3000 (the first tests run on a Radeon 4870HD): 62, 178, 124, 163, 97, 207fps. VBO with triangle list is much faster this time. I'm starting to be confused...


If you gave us more details about the way you have measured the time, maybe we could find the cause. SwapBuffers is not a time-consuming instruction. The reason it take time is waiting for drawing to finish. That implies your measured time is incorrect. How did you measured it?

#5015068 Good books for OpenGL

Posted by on 28 December 2012 - 08:11 AM

Weird that no one linked Arcsynthesis biggrin.png


Its a free online book, [cheaptactic]endorsed by John Carmack himself[/cheaptactic]. Deals with OpenGL 3.3.
Yes, this is a nice and comprehensive tutorial, but without offense, each of the listed books is much better resource for learning OpenGL.
Regards for McKesson. He really did a great job.

#5015056 Good books for OpenGL

Posted by on 28 December 2012 - 07:11 AM

Is there other books that could help me out with programming with OpenGL?

thanks a lot! smile.png

what do you say about:



If there is some books that you find it really be great if you give me it's name smile.png


Those links are awfully old. For absolute beginning, they can serve the purpose, but they are all about legacy OpenGL.

I could recommend the following books:


- OpenGL Programming Guide: The Official Guide to Learning OpenGL, Version 4.3 (8th Edition) by Dave Shreiner, Graham Sellers, John M. Kessenich and Bill M. Licea-Kane (Apr 1, 2013)

- OpenGL 4.0 Shading Language Cookbook by David Wolff (Jul 26, 2011)

- OpenGL SuperBible: Comprehensive Tutorial and Reference (5th Edition) by Richard S. Wright, Nicholas Haemel, Graham Sellers and Benjamin Lipchak (Aug 2, 2010)

- OpenGL ES 2.0 Programming Guide by Aaftab Munshi, Dan Ginsburg and Dave Shreiner (Aug 3, 2008)

- OpenGL Shading Language (3rd Edition) by Randi J. Rost, Bill M. Licea-Kane, Dan Ginsburg and John M. Kessenich (Jul 30, 2009)

- OpenGL Insights by Patrick Cozzi and Christophe Riccio (Jul 23, 2012) 


The first book in the list is not released as a hard-copy, but can be bought as "rough cuts" on various sites.


The only book you need is GL 4.3 specification, http://www.opengl.org/registry/doc/glspec43.core.20120806.pdf from http://www.opengl.org/registry/


The specification is not a book, and should not be recommended for learning OpenGL!

#4996828 uniforms

Posted by on 03 November 2012 - 05:34 AM

I'm on AMD with only OGL4.2 drivers... I guess I'll have to stick with glGetUniformLocation...
as for the why: I just wanted to get rid of keeping track of uniform locations. It's not that cumbersome, but it would be great if I didn't have to.

T thought you are using NV hardware, since only NV currently has GL 4.3 support.

Well, I don't agree that getting uniforms' (or attributes') location is cumbersome, especially because that should be done only once, during the initialization phase.
I'm using class-wrapper for each shaders. Uniforms and attributes locations are attributes of the instance, and they are set in the Init() function (at the same place where I load and compile shaders, and link the program). After that, I just call appropriate function (method) of the particular object to set values. It cannot be easier.

Another remark: Setting attribute location is also not correct in your code, because you are wasting 4 locations.
layout(location=0) in vec4 in_vertex;
layout(location=5) in vec2 in_texture;

In the unpacked format, both vec2 and vec4 consumes just one location. In your case, layout is like follows:
location 0: | in_vertex.x | in_vertex.y | in_vertex.z | in_vertex.w |
location 1: | < empty > | < empty > | < empty > | < empty > |
location 2: | < empty > | < empty > | < empty > | < empty > |
location 3: | < empty > | < empty > | < empty > | < empty > |
location 4: | < empty > | < empty > | < empty > | < empty > |
location 5: | in_texture.s | in_texture.t | < empty > | < empty > |

As you can see, there is a lot of wasted space. So, if you don't have a particular reason to define layout and reuse it across multiple shader-objects, It would be wiser to just let compiler do it, or read specifications to see how it actually works.
Happy coding! Posted Image

#4996563 screen Hz

Posted by on 02 November 2012 - 09:44 AM

By drawing it on the screen. If vsync is on, you cannot draw it with other rates except f, f/2, f/3, f/4, etc.

#4996521 uniforms

Posted by on 02 November 2012 - 07:28 AM

Why do you need this feature? If it is for the learning sake only, please wait until stable drivers release.
There are several sources of the problem.

What drivers are you using? GL_ARB_explicit_uniform_location is the part of GLSL 4.3 core spec, not 4.2. If you are using NV 310.xx drivers, then there could be a bug, since they are in a beta phase. If you are using previous releases, then you should check whether the extension is supported and probably enable it explicitly in GLSL (if it is supported).

I guess you don't have support GL_ARB_explicit_uniform_location and the reason it works for the first uniform is accidental correspondence with compiler's associated locations. NV uses alphabetical order of names. So, locations are as follows:
0 - mvp
2 - texture0
1 - overlay_color

Before trying to use some new feature check if it is presented and read specification to understand how it works. ;)

#4986195 Missing GL_ARB_robustness

Posted by on 02 October 2012 - 02:54 PM

I have to apologize because my statement number 6 is not correct.

6. If the driver supports particular ARB extension it also supports core equivalent and vice versa. ... Well, if the core version exists, both ARB and core functions point to the same entry.

I carried out some experiments, and they proved that core, ARB and EXT versions of the same function may point to different entries.

#4945253 gl_ClipVertex alternative

Posted by on 01 June 2012 - 03:48 AM

Better to post something than nothing to get him trying something.

Strongly disagree! If the pointer is wrong, he could get lost.

Your response was only a day later than mine and I've never seen your name in the GL forums in the 7 years I've been on it, so I actually know quite a bit. Stop being a douche.

Sorry for being impulsive! You wrote something that was not right I reacted for the sake of beginners that might be reading this.
I haven't posted anything on this forum for a while. But I am pretty active on opengl.org with my real name. Posted Image
Whatever, it doesn't matter.

And the reason it wasnt nonsense is because if you dont write gl_FragDepth, it is taken care of before the pixel shader and early z-discard takes place before the shader. I assumed it might happen for clip planes in the current specs.

Posted Image What is a connection with fragments and discarding? Totally wrong assumption.

#4945102 gl_ClipVertex alternative

Posted by on 31 May 2012 - 03:47 PM

I am using opengl version #140 with C++ and visual studio professional.

It is GLSL version 1.40, not OpenGL version. The corresponding OpenGL version is 3.1.

Try not forcing #version or whatever in your shader.

#version is very important directive! If not used GLSL 1.1 is assumed. So, DO use #version. NVIDIA is quite permissive. AMD is not.

did you try writing the array at [0] and [1] ? I assume that it just works under the hood that when you compile the shader it knows you will only clip 2 planes.

This is ridiculous! If you don't know the answer, please don't write such nonsense.

1. Clip distances have to be enabled by
glEnable(GL_CLIP_DISTANCE0 + i)

2. Send clip planes as uniforms to your vertex shader.

3. Calculate glClipDistance[i] as a dot product of clip-plane and the vertex position vector.

Only the sign is important, not the value. If the distance is negative, the vertex will be clipped. The vertex and clip plane have to be in the same coordinate system in order to have a valid result.