Preparations for upgrading to OpenGL 3.0

1.)So my first question is I read in the documentation that OpenGL is doing away with glBegin/glEnd commands. I’m curious if anyone has any idea how this will work yet? How will you declare your primitive types (GL_TRIANGLE_STRIP, GL_QUADS, ETC…)?

2.)Are there any things folks can think of to start preparing my code for migration to 3.0?

3.)I use an NVidia 7800 series card in my laptop right now. Will that be compatible with 3.0 or will I have to upgrade to the 8M series? If I don’t upgrade what features would be unavailable?

4.)If an upgrade is necessary which do most folks prefer ati or nvidia for OpenGL applications and best bang for your buck?

5.)Does anyone know of a site that sells laptop videocards individually? Thus far all the places I have looked have had only sold them in cutom or premade laptops.

I know some of this stuff is not OpenGL specific questions but it’s all ballpark get ready for 3.0 stuff so any help is appreciated. Also I know it might be too early to tell on some of this stuff, just looking for thoughts.

Thanks!

  1. OpenGL ES is very instructive here, it uses glDrawArrays and glDrawElements exclusively.

The primitive type is still specified with the first argument in these API calls but the attributes are bound outside the call.

Also moving forward with ES 2.0 explicitly reserved attribute meanings/semantics are gone, you simply number them and associate them with variable names in the shader. This is closely coupled to the fixed function pipeline being eliminated so this will happen in OpenGL 3 also.

  1. Use glDrawElements now for EVERYTHING and use a cache coherent tristrip generator (like nvtristrip, it’s Open Source) if code allows or stitch your own strip indecies manually (this is quite possible in many scenarios). Use degenerates to aggregate many triangles and to swap winding if needed.

Steer away from using any fixed function pipeline and use shaders even where you don’t need to (at least have a code path which does this).

Use generic attributes in your vertex attribute array bindings and in your shaders.

Roll your own matrix manipulation classes and start to use them merely specifying matrix attributes to your shaders.

Abstract texture handles and shaders so you can move to the new object model simply. Maybe look at using VBOs for vertex allocation but again abstract it.

  1. dunno, probably, but a lot of the right code should be portable. glDrawElements, shaders and generic attributes all work on that platform today. This is more of a driver issue and a personal choice. I think you could maintain code that is largely 3.x compatible on 2.x hardware. Whether you need access to additional 3.x hardware will depend on NVIDIA’s driver priorities.

  2. Laptops are strange and custom animals. I like my GeForce Go, nvidia does a fantastic job with these, but it struggles a bit with Bioshock :-). The main features unavailable would be geometry shaders. If they don’t do some kind of driver release for it (and they may not) then you’d be missing the new object model & texture filter split, but these are probably simply manageable by supporting multiple codepaths.

  3. Geeze most people have difficulty upgrading their laptop drivers and you want to upgrade the video card!!! :slight_smile: Good luck with that. FWIW I’d be interested in an answer to this too :-), I did manage to upgrade my drivers using hacked .inf downloads. I don’t think you’ll need to upgrade hardware though. You can have a compatible 2.x codepath today using what I’ve described. If your code currently does glBegin glEnd and uses the fixed function pipeline then you’ll have more than enough to be getting along with. I doubt you’ll be exploring geometry shaders or anything that won’t run on a 7 series on 2.x when OpenGL 3.x arrives.

Wow thanks for the awesome answers. That will give me enough to work on for some time. I travel quite a bit so the laptop was the only good development option unfortunately… and I’m fairly sure I can get the boss to spring for a new video card but an entire new laptop is a whole nother animal. I’ll keep you up to date if I find any sites that sell the cards themselves… I am going to try going through laptop service centers. If anyone else has any thoughts on this one let me know!

P.S. there are more efficient dispatch mechanisms the glDrawElements which tell the driver in advance the amount of vertex data that it must load in advance and is amenable to efficient DMA without index checking.

e.g. glDrawRangeElementsEXT

But there are vendor specific variations on this theme. These methods should probably be preferred and I expect will be important and core in 3.0 also. Non ranged versions will probably remain.

Also moving forward with ES 2.0 explicitly reserved attribute meanings/semantics are gone, you simply number them and associate them with variable names in the shader. This is closely coupled to the fixed function pipeline being eliminated so this will happen in OpenGL 3 also.
I wouldn’t necessarily expect to have to number them. Instead, I would expect that the VAO would have a string name for each attribute that is intended to match with the string name for an attribute in the vertex shader.

At least, I hope they do it this way. I’d rather not have to create arbitrary numbers myself.

Use glDrawElements now for EVERYTHING
Or glDrawArrays. Where appropriate.

Generic vertex attributes specified by glVertexAttribPointer are numbered using the first argument, there will be no fixed function labels (and therefore no glNormalPointer etc.). These numbered attribute bindings are linked to attribute names used by the glSlang code.

DrawArrays is inherently less efficient except for trivial stuff, and by trivial I mean very trivial, there’s a lot of even trivial stuff that benefits from indexed optimization. Both because vertex cache can be employed and because degenerate rejection is invoked early eliminating T&L. It really goes back to data processing and content, if glDrawElements is not worthwhile you usually have other issues although not always. Using glDrawElements when you should be using glDrawArrays is a lot more benign than the reverse IMHO. So, notwithstanding your technical exception I stand by my generic advice.

Originally posted by dorbie:
[b] Generic vertex attributes specified by glVertexAttribPointer are numbered using the first argument, there will be no fixed function labels (and therefore no glNormalPointer etc.). These numbered attribute bindings are linked to attribute names used by the glSlang code.

DrawArrays is inherently less efficient except for trivial stuff, and by trivial I mean very trivial, there’s a lot of even trivial stuff that benefits from indexed optimization. Both because vertex cache can be employed and because degenerate rejection is invoked early eliminating T&L. It really goes back to data processing and content, if glDrawElements is not worthwhile you usually have other issues although not always. Using glDrawElements when you should be using glDrawArrays is a lot more benign than the reverse IMHO. So, notwithstanding your technical exception I stand by my generic advice. [/b]
Regarding glDrawArrays(), what about rendering large sets of points (e.g. particle systems)? That doesn’t seem like a trivial case.

Your laptop manufacturer will have video card upgrades. I’ve seen one site show an upgrade with lots of photos. The card had a weird shape. It looks nothing like AGP or PCIEx, although I think it was PCIEx. Worst of all, there isn’t much information on laptop upgrades.

I custom built my latptop through cyberpowerPC which has worked out fairly well thus far it’s a huge beast, but I bought it that way intentionally so everything could be upgraded. I will try contacting them to see if an upgraded video card can be purchased.

e.g. glDrawRangeElementsEXT

But there are vendor specific variations on this theme. These methods should probably be preferred and I expect will be important and core in 3.0 also. Non ranged versions will probably remain.
I wouldn’t be surprised if the VAO innately stored the equivalent of a “range”. Either implicitly by examining the element buffer object or explicitly by the user telling it the range.

It makes more sense than having a bunch of different types of glDraw* entry-points. And entry-point reduction is something they seem to be interested in, since they have only two glDraw* calls, and both have a lot of parameters.

Generic vertex attributes specified by glVertexAttribPointer are numbered using the first argument, there will be no fixed function labels (and therefore no glNormalPointer etc.). These numbered attribute bindings are linked to attribute names used by the glSlang code.
I think you misunderstand what I was saying.

In GL 2.x, glslang attributes are given a number, one of which must be assigned to 0 for legacy Begin/End compatibility reasons.

In GL 3.x, there’s no need for assigning numbers. VAO’s encapsulate binding points for arrays. So it is entirely possible for VAOs to use string names rather than numbers. That way, if any vertex shader has an attribute called “Position”, any VAO that uses the attribute “Position” will automatically bind to it. That way, linking is very easy. No need for number mapping nonsense.

DrawArrays is inherently less efficient except for trivial stuff, and by trivial I mean very trivial, there’s a lot of even trivial stuff that benefits from indexed optimization.
It’s mostly for stuff that you were going to use glBegin/glEnd for. Sprites, font letters, one-off GUI stuff, etc. Basically a string of quads that are not necessarily connected to one another.

Originally posted by Korval:
[b]

In GL 3.x, there’s no need for assigning numbers. VAO’s encapsulate binding points for arrays. So it is entirely possible for VAOs to use string names rather than numbers. [/b]
I hope they will do it that way…

Originally posted by Rodan:Regarding glDrawArrays(), what about rendering large sets of points (e.g. particle systems)? That doesn’t seem like a trivial case.
That’s an excellent question which I’d like the answer to as well. In my case it’s not a particle system, it’s histogram scattering----which means I need to use glBlend to accumulate. I’m operating on something like 15000 GL_POINTs. Will the blending mask any efficiency difference between glDrawArrays and the other options, or are those two operations sufficiently independent that it won’t matter?

@rodan, I’d say it’s the most trivial case of all, but it’s a matter of opinion.

Font letters etc. should be stitched with degenerates and drawn using indexed strips with degenerates, I actually had this in mind as I typed the reply. You could contrive a use once tristrip or the points mentioned elsewhere. Touch once data may be prefferable if the driver is optimized for it, that’s a big if. (P.S. just to be clear the motivation here is earlier trivial rejection of degenerates, OTOH quads might be a better option and you’re back to arrays but I’ve seen mixed results but not on the platforms you’re familiar with YMMV). I figure if you give out the generic info, anyone who is smart enough to know when to use DrawArrays will innately know to use it anyway, anyone else is just better off sticking to DrawElements, I know which is the side of caution on which developers should err.

On VAO’s that’s one option, hopefully though I’ve clarified my position and made it clear what the migration path is on current hardware with current APIs.

@Lindley, with points it is probably correct that glDrawArrays is the best approach, however consider a scenario where one can use the same point set resident in memory and different index lists to alter the point density and instantly cull points. Of course indecies are not limited to reducing density, they could act as an aggregate culling mechanism (including back face surface patch). It depends a lot on the details. In general I’d say glDrawArrays should be the right approach for points with the right drivers, notwithstanding other smart things you could use index list manipulation for, and as always YMMV.

Are there any things folks can think of to start preparing my code for migration to 3.0?
I’m planning on doing some light stretching, and perhaps a few push-ups. Then once Mount Evans arrives, I’m going in for a complete overhaul.

@modus HAHAHAH!

Originally posted by dorbie:
@rodan, … but it’s a matter of opinion.
Roger that.