Pointer to Framebuffer

I’m sure there are many technical reasons why this would be a tough thing to do, but it would be nice if you had a way of retrieving a pointer to the framebuffer memory. This way we wouldn’t be forced into the glReadPixels, glWritePixels which prove to be much too slow IMHO.

I realize that GL is designed to work across a network, but what about when the Server,Client are the same machine? In that case, why not make the function available. Possibly by implementing some flag that can be read that indicates if it is/is not possible to retrieve a pointer to the framebuffer.

The question is, what would you do with this pointer? Reading directly from the card would always be slow, no matter how you do it.

Maybe a better choice would be a “raw framebuffer” extension, similar to NVIDIA’s Z+stencil extension.

There have been several discussions about this before.
http://www.opengl.org/discussion_boards/ubb/Forum7/HTML/000077.html

I think this one covered the topic pretty well.

j

Unfortunately the other topic seemed to wander off into getting pointers to Texture memory.

I read all of the posts and have went back and forth on the issue. On the one hand, you have D3D’s miserable experience with pointers, however I don’t see why D3D was even brought up, it certainly is usually bashed in these forums.

Providing a pointer in and of itself is not the problem, it’s the fear of what will be done with this pointer, or that it won’t be handled correctly by applications.

I have programmed VGA and SVGA using the VESA bios extensions back in the ye old DOS days, and it was complicated indeed, but I studied how to do it, and got it working. Then I started Windows programming and tried my hand with DirectDraw. It was complicated, but I learned it, and got it working, but it was slow. Then I tried creating my own buffer and doing the swaps via fast Assembly language routines. Worked out about twice as fast. My video card isn’t the hottest thing since sliced bread(an ATI Rage Pro), and yet writing my own backbuffer, blitting routines was much faster than the DirectDraw FlipBuffer.

Now along comes OpenGL. I have no hardware acceleration as I have to use non-OpenGL compliant drivers. I learned to use glReadPixels, glDrawPixels, it wasn’t hard, but it was sloooooooow. I’m talking orders of magnitude slower than DirectDraws FlipBuffer routines. So slow in fact that I would not even consider using OpenGL for 2D games, applications.

I resent the comment in the last thread that we should all run out and by Geforce II’s if we want speed. If that isn’t getting hardware specific, than tell me what is? I mean hell, if everyone goes out and buys a G2, then we can all get any features we want under the sun as there will be a single card manufacturer left.

So until all of us go out and buy G2’s(never gonna happen) hows about a pointer. Yes, it may be hard to program, and many may abuse it, but that is the case with anything. And lest everyone forget, not all of us actually get improved performance letting the hardware take over, sometimes it is faster, much faster to write your own buffer routines.

Hello,

there are a number of reasons why ptrs are bad. Some even take the view (and can convingly argue) that pointers are even bad in languages like C because it makes it impossible to know about side effects. (I can’t remember the quote exactly, but someone once said “pointers are like gotos, an error from which we may never recover”, or something.)

Anyway, the merits and potential pitfalls of pointers in languages isn’t what this is about.

I just wanted to make the observation:

Silicon Graphics machines have never exposed a memory mapped frame buffer. I appreciate that not everyone has an Onyx; but, then, that isn’t my point…

cheers,
John

And…as far as pointers being bad per se, or not working correctly, well that is not entirely correct. I have a commercial software program that uses direct writes(via assembly language routines) to the fornt buffer created in DD. This program has been used succesfully on thousands of different setups with graphics cards from all manufacturers. I have yet to receive a single complaint of any lockups, BSOD’s, or irregular display results. This program has been out for over two years now. This program works in 16/24/32 bit depths, and multiple resolutions. It even works on a ancient 486 with no video card.

I didn’t do anything magical, just obtained a pointer to the buffer and blasted it into it using a method very familiar to Assembly programmers-

rep movsd

[sarcasm]Now I realize that is a pretty sophisticated line of code there, and I’m sure it could be trimmed down a bit.[/sarcasm]

I’m sure that it could be implemented in OpenGL and it would allow GL to finally have some worthwhile 2D aspects. DirectX has DirectDraw, but as of yet, OpenGL has-

glReadPixels
glWritePixels
glCopyPixels

So, I need to allocate some system memory for my data, then using glWritePixels to copy that to the framebuffer? Sounds slow to me. So how is that avoiding System ram?

I think the reason DirectX is so popular is all of the capabilty it has. DirectDraw, D3D, DirectSound, DirectPlay, DirectMusic, have I forgot some? How about a little of that goodness in OpenGL?

How about a pointer?

OpenGL, despite the name’s implications of being a graphics library, is mainly a 3D library. It is designed as an abstraction to hardware, so that you neither have to, nor are permitted to, directly access the hardware in any way.

Besides, there’s more than one way to solve a problem. Ignoring page flipping for a moment, OpenGL’s texture mapping facilities are quite good for dealing with the issue of getting a bitmap on screen (assuming texturing is hardware accelerated. And, virtually any OpenGL-compliant card provides this). It does good rotation and scaling (as good as the card, at any rate).

And, as long as information goes in one direction, ie. towards OpenGL, it is reasonably fast. True, OpenGL makes it intentionally difficult to interface with things by yourself, but if you did that, what would you need with OpenGL?

Accessing a frame buffer directly is more complicated than it would be for 2D, and while 2D buffer formats are likely to remain the same in the future, 3D ones change more easily. For example, it may be that the back buffer is 4 times the size of the front buffer, because the user has enabled antialiasing. Or, the same can be done by creating four different buffers, which are later combined by the hardware when outputting to the screen. Using OpenGL functions can hide such complexity from you.

> So until all of us go out and buy G2’s(never gonna happen) hows about a pointer.

The problem is, even if this becomes part of a future OpenGL, it won’t help you a bit in getting more performance out of older chips. Chip makers will have to provide a compatible ICD for their older chips, and they don’t even provide OpenGL 1.2 compatible ICDs now, so they’re unlikely to be compatible with an even newer version.

BTW, DirectDraw is also pretty much dead. It’s not even in the DirectX documentation these days, even though it’s still lurking in the background. DirectGraphics supports 2D sprites using the 3D hardware, which provides more flexibility. To paraphrase Korval, “DirectGraphics, despite the name’s implications of being a graphics library, is mainly a 3D library.” You’ll find very few 2D games these days, and fewer still as time passes. So while OpenGL may not be suitable for 2D games, who wants 2D games??

And about the “never gonna happen” believe me that in four years you’ll find it hard to come up with a chip that’s not as powerful as a GeForce.

> I have no hardware acceleration as I have to use non-OpenGL compliant drivers

Why do you have to use non-OpenGL compliant drivers?

There are many cases where it would be nice to have direct access to the framebuffer. I’ll use a screen saver I wrote for an example. The program calculates interference patterns using highly optimized Assembly routines and buffers. I would like to be able to incorporate 3D shapes as well, however that sticks me into a bind. I can’t use OpenGL’s Draw Pixels as it is far too slow, but to render the 3D shapes manually in software would be too slow. So I need a pointer. I can do this using DirectX and that is what I feel is missing in OpenGL.

Using OpenGL functions can hide such complexity from you

I am perfectly happy learning whatever it is I need to access the framebuffer. OpenGL is supposed to be ‘low-level’.

The problem is, even if this becomes part of a future OpenGL, it won’t help you a bit in getting more performance out of older chips. Chip makers will have to provide a compatible ICD for their older chips, and they don’t even provide OpenGL 1.2 compatible ICDs now, so they’re unlikely to be compatible with an even newer version.

I do understand that previous boards will not recognize this. That is why one would need to query the particular card at runtime to find out. I believe this needs to be done with extensions currently, so how is this any different?

So while OpenGL may not be suitable for 2D games, who wants 2D games??

That is a narrow viewpoint and really not a good argument against having pointers. There are many cases where a pointer would help, not only in 2D games.

Why do you have to use non-OpenGL compliant drivers?

The computer I have uses an ATI Rage Pro but the latest OpenGL1.1 ‘compliant drivers’ are not at all functional. I get BSOD’s, lockups, no textures in some apps, and scanning problems. I have attempted to try several different drivers and none work save the driver from '98, therefore I am stuck in software-emulation mode. I don’t mind as I have found out many little tricks to getting OpenGL faster and I can readily achieve 10-12 fps in the Model Editor I am finishing up. I look at many demos, example programs and such and find them running 1-2 fps.

It seems that the Cards are a double edged sword. On the one hand, they have caused many gains in speed and made programmers jobs easier, on the other hand, they have also created lazier programmers. I guess I’m really old school where squeaking a byte or two out of some optimized assembly code was the thing to do. Efficiency was the call of the day. Nowadays, it’s ‘shut up’ and let the card do it for you. I believe I remember those very words when Windows came out.

I still want my pointer.

The point of “using OpenGL functions can hide such complexity from you” was that, unlike 2D, you can’t “happily learn” what you need, because there can always be another method of display that you didn’t program for. So you took a certain method of antialiasing into account (for both 2x,3x and 4x AA) - but what if the driver has a switch that enables automatic stereo support?

The comment about old chips was because you referred to them as a target for programs, and used the “we can’t all buy a GeForce” argument. My point was that even if such an extension is approved, it will likely be only the GeForce level cards that implement this extension anyway.

And I don’t think that the speed gains made programmers lazier. If you start doing some 3D programming, you’ll learn that tweaking bytecode is not the most effective way to optimize 3D programs. I think that it will be hard for you to realize, because you’re using software rendering.

Don’t get me wrong, I can still see how a faster read/write pixels routine could be helpful, but I think that you’re overrating the pointer thing.

I still don’y understand exactly what you are trying to do that requires glDrawPixels. If you generate, through an optimized assembly routine, some 2D image, you can get it onto the screen easily (and quickly) enough by texturing it to a qaud and rendering that.

Also, don’t forget OpenGL does have functionality for running on other machines and piping the results to yours. In this case, the pointer you seek is far beyond the reach of your program.

Lastly, I’ve always prefered the “shut up and let the card (or somebody else in general) do it for you” approach. That way, you spend more time on the actual application rather than optimizing fast-block copies and the like.

Korval, my guess is that he’s changing the image every frame, which is why he needs to upload an image to the card each frame.

Sheepie, assuming that this is what you need, it’d still be better to do with a texture. It may even be faster than using a pointer.

The point is (stupid pun), when you get a pointer, you have to prevent the card from doing any rendering at that time. That’s one good way to slow down a card. If you put your image into a texture, you could integrate it into the normal rendering process, which is what a 3D card does best. This will also add a lot of possibilities for you, such as warping that background, or using it as a texture, or a bump map, or whatever.

Perhaps you should try using glTexSubImage2D to get that image of yours into a texture. Could well be faster and more interesting than glDrawPixels. Maybe not on a software implementation, though.

I think the point I was trying to make is that I am NOT concerned with the specific implementation on the card itself. I have a Device Context to the Window already, although you obviously can’t use it unless you want it to be overdrawn.

I made the G2 observation from the other post that made the point that all people should go out and buy G2’s.

Where did you learn that speed gains don’t make programmers lazier? It most certainly does. Case in point…Windows. Am I the only one that notices the enhanced bloat and slowdown associated with each new release? And yes, if I can make a 3D modeling program that kicks out 10-12fps with texturing and blending, why is it that every demo, or GL application I have run into is running something on the order of 1-2fps. My guess is that no thought was put into software only setups, and that is being lazy however you sugarcoat it.

I can not use a Texture for the reasons mentioned. Each image is calculated on the fly and stored in a buffer. That buffer is the buffer give to me by DirectDraw. Your way would require writing the data first to a seperate buffer and then using glTexSubImage2d to get it to the card. I can’t even begin to imagine how slow that would be for a full screen 1024x768 32bit resolution. I’ll bet it’ll be far slower that the 100 clocks/pixel I get currently. I imagine an order of magnitude slower as transferring all that data would be fierce.

As far as the pointer not being available from another machine. I specifically mentioned that in my post above.

You may prefer the ‘shut-up and let the card do it’ approach, but I like to know the in’s and out’s of the things I program. If everyone took that approach, it would be a sorry state of affairs in the programming world.

As far as preventing the card from drawing to the framebuffer. How about this-

Draw 3D scene
glFinish
Draw 2D stuff
wglSwapBuffers

Now I must have misread the manuals when I read this-

The glFinish function does not return until the effects of all previously called OpenGL functions are complete. Such effects include all changes to the OpenGL state, all changes to the connection state, and all changes to the framebuffer contents.

Sounds to me like I could get my pointer and start drawing.

Sheepie, I think that you’re putting a strange meaning to the word “lazy”. If one programmer brings out a great looking product with a lot of features that runs slowly, while another programmer brings out a limited product that runs very quickly, does that make the first programmer lazy? Quite the opposite. I think that it can often be more difficult and more work to produce a fully featured product that takes advantage of modern hardware than to tweak code to make it run more quickly.

How is not optimising for software OpenGL being lazy? The vast majority of users have hardware accelaration. IMO it would be a waste to invest a lot of time for a minority of users, when you could invest your time in making your software better. I would also suspect that those users who run software OpenGL don’t buy products that need OpenGL, since for the price of a game (or less), you can buy a 3D card that does support OpenGL in hardware.

I disagree with you about the state of affairs. I think that it’s much better when programmers take full advantage of the hardware, instead thinking of ways to bypass it.

Regarding your specific app, I don’t understand why you’d use the DirectDraw buffer. Why not allocate your own buffer, do the calculations in it, and write it to a texture? Should be easier, less limiting, and faster. From your description, I’d guess that you have to copy to another buffer for glDrawPixel, too, which would explain part of the slowness.

As for the glFinish(), yes, that’s exactly what it does, even though I’d think that you would want to draw 2D first (I thought you were drawing on it). The point was, you’re stalling the card to do your 2D. If you let the drivers/card do it with texturing, it could perhaps go something like this: you tell the driver to load the texture, the driver copies it to AGP memory (meanwhile the card is drawing your objects), and tells the card it’s there. The card can then textures the background directly from AGP. I’m not saying that this is the exact way every (or any) card would do it, but you can see how you’re not stalling the card in this way.

Sheepie, I think that you’re putting a strange meaning to the word “lazy”. If one programmer brings out a great looking product with a lot of features that runs slowly, while another programmer brings out a limited product that runs very quickly, does that make the first programmer lazy? Quite the opposite. I think that it can often be more difficult and more work to produce a fully featured product that takes advantage of modern hardware than to tweak code to make it run more quickly

I have developed both so I wait to stand corrected. If you don’t think it takes work to optimize code then maybe you haven’t coded assembly. I am not going to even try to incite a flame war as that would be unproductive, but as of late, many programmers simply view programming as features and add speed later(if at all). It only takes a small amount of planning and a state of mind to write efficient code from the get go. I’m not suggesting you should go as far as unrolling loops(that is no longer a proper optimization method), but there are many ways to write the same piece of code.

How is not optimising for software OpenGL being lazy? The vast majority of users have hardware accelaration.

O.k., maybe you think we should all go out and buy G2’s. You’d make a great salesperson for NVidia. I think you may think everyone and his Uncle has a great system with great specs. Sorry to break it to ya, but most of the people with high-end systems are gamers. While the gaming community may be large, it is not the majority. Maybe you think everyone has high-speed internet connects as well?

And as far as the lazy factor, yes, it’s a strong word but unfortunately true. They may have some fast card in their system and the ‘it runs ok on my system, but a new card’ may work fine if your only talking demos and such, but it does not work if you are selling it. And you know what’s funny? My software only optimized GL modeling program runs twice as fast on Hardware then a competitive program.

IMO it would be a waste to invest a lot of time for a minority of users, when you could invest your time in making your software better.

Your opinion is not unnoticed, again. Making your software better? I thought making things faster was part of that?

I disagree with you about the state of affairs. I think that it’s much better when programmers take full advantage of the hardware, instead thinking of ways to bypass it.

I kinda figured you disagreed from the huge number of replies. What if the hardware isn’t there or doesn’t support a feature? Fallback to non-optimized software.

Regarding your specific app, I don’t understand why you’d use the DirectDraw buffer. Why not allocate your own buffer, do the calculations in it, and write it to a texture? Should be easier, less limiting, and faster. From your description, I’d guess that you have to copy to another buffer for glDrawPixel, too, which would explain part of the slowness

So I would need to allocate a buffer, draw to it, create a texture or modify existing with glTexSubImage2D. Sounds like two writes to me? Am I mistaken?

As for the glFinish(), yes, that’s exactly what it does, even though I’d think that you would want to draw 2D first (I thought you were drawing on it). The point was, you’re stalling the card to do your 2D. If you let the drivers/card do it with texturing, it could perhaps go something like this: you tell the driver to load the texture, the driver copies it to AGP memory (meanwhile the card is drawing your objects), and tells the card it’s there. The card can then textures the background directly from AGP. I’m not saying that this is the exact way every (or any) card would do it, but you can see how you’re not stalling the card in this way

I would still need to do 2 writes. One to my buffer, and then when the driver needs to upload it onto the video card. Then the whole process repeats on the next frame. I can not see how that is going to be any quicker than having a *pointer.

Please explain to me how your method is any faster than direct writes to the framebuffer, or even to the display buffer when it has to be written each and every frame? If the answer is it won’t be, then where is the harm in providing a pointer? If you don’t wish to use it, don’t. I personally am sick of big companies telling us what we need. It is a vicious circle. They add a feature in hardware, then take a feature away in software in the guise - ‘it’s good for you’ The only ones it’s good for is those that sell the hardware. We eventually will become so dependant on hardware to do every little thing. This is called the ‘dumbing down of programmers’ and is a well known phenomenon that has been happening ever since the first computers.

I have optimized assembly (when it was still a useful thing to do), and it is thoughless work. It’s applying a set of rules and measurements. True, it can be tricky, but IMO there’s much less thinking involved than getting a good looking 3D effect to work, or using the right space subdivision and LOD algorithms to speed up your code (which, believe me, is much more effective than low level optimising a bad algorithm). You can still gain some speed by using assembly code (like SSE) for specific things, but it’s the last thing a programmer should do, IMO.

I’m not saying get a GeForce2 (although the MX versions are getting pretty cheap). Just buy an 8MB TNT2 M64, for heaven’s sake. It can be found for under $30, and it will accelerate OpenGL for you. If you can’t afford it, then most likely you can’t afford any software that uses OpenGL, unless it’s freeware, in which case you’ve got no right to complain

In case the hardware doesn’t support a feature, the fall back is to use fewer features. I don’t plan to support software OpenGL at all, and I’d have loved to be able to detect software rendering, and be able to adjust the features I’m using accordingly. If you did want to support software rendering, I’d program (or buy) a software engine, since it’d be much faster than a generic OpenGL implementation.

But I don’t think that a software engine is a real necessity these days. I don’t assume that everyone and his uncle has a great system, but I’ll probably be not too far off the mark assuming that most users have rendering power at least the equivalent of a 300MHz CPU and the i810 integrated chipset.

About your program: in the current state of affairs (no pointer), you always need to first create your data in a buffer, and then copy it to OpenGL. My suggestion was to copy to a texture instead of to the display buffer. The number of copies is the same, so this method shouldn’t be any worse.

Why the texture method is faster than the pointer method: it’s called parallelism. Read back my description. With the texturing method, all the time that you’re calculating your image and copying it to AGP, the 3D card can do work.

Hello,

McCraigHead has eloquently explained why pointers to video memory is a proverbial bad thing. It won’t happen, and your arguments FOR it and your arguments against not having it (!?) are misdirected, IMHO.

The motivating argument seems to be that glRead/Draw pixels is too slow and a stubborn refusal to use texture mapping as a method of uploading bitmap data to the card is a good reason to get a pointer to video memory because it will be (somehow) faster. Why? You might equally suggest that your harddisk is too slow, so you must have a memory mapped harddisk pointer, or that you’re unhappy with your laser printer’s printing speed, and so want a pointer to that, too.

Why will a pointer make transferring bitmap data to the card faster? The consensus seems to be that having a ptr to video memory will eliminate the need for a duplicate copy of the image in system memory and it’ll get around calling glDrawPixels(). This can, argubably, reduce bus traffic since the data is going straight to the video card and therefore only needs to use the bus once. (Although the second transfer from system memory can be done with DMA.)

It is not just as simple as getting a pointer to video memory and merrily reading/writing to it at whim, however. Video access has notoriously been slow. The original poster would have rememebrd this from his DOS VGA/SVGA coding days. Remember how reading from the video card seemed to be a feature the h/w vendors only added for backwards compatiblity? Reading/writing to video memory isn’t going to run at the same speed as reading/writing to system memory. Your argument for speed up is that your combined read/writes to system memory and transfer to the video card is slower than the read/writes to a slower resource.

Another argument prposed by some is that since OpenGL is meant to be low level, then it should provide a pointer. This isn’t the point of OpenGL. OpenGL is a low-level abstraction of the graphics hardware. Abstraction, by its very definition, hides away the implementation details. (So, by the very defn of abstraction, then OpenGL SHOULDN’T expose a pointer to the programmer.)

Suppose that you could get a pointer to the graphics display. How is the programmer going to be able to USE this pointer? Someone talked about using a string instr to blit the image across, but this is fairly naive. Who says that the video memory is linearly addressed, or that the data is encoded in RGB triples on byte aligned boundaries, or any other myriad of schemes?

Someone retorted that learning pixel formats is no different from learning new techniques off the advanced graphics forum, but this is naive also. Device drivers exist so programmers don’t NEED to learn how different hardware is structured. Doesn’t anyone remember the pain of non-standard SVGA cards? How some games only supported three major SVGA cards because they were all different until VESA brought out a common interface?

Suppose, however, that a pointer was available, and (as someone suggested) the programmer could figure out how the pixel format through some interface extnesion string, then what happens when a NEW pixel format comes out? Does the application suddenly break because it can’t understand that this new pixel format isn’t linearly addressed, but uses bitplanes and stored in seperate buffers for each R G B, or something equally perplexing?

Ultimatetly, however, graphics cards are another shared resource, and they need to be controlled by the operating system. In the same way that an appliction can’t have direct access to a disk because the o/s doesn’t trust it to respect the file system, and in the same way a program’s printer output must be spooled so multiple applications don’t try and print simultaneously, the o/s has to know how the graphics resource is being used. Just because an application might request a window doesn’t mean that it owns that window all the time. Its fairly easy to show that (under IRIX, for example, at least) that buffers are shared between windows. (If, for example, an application just captures even the back buffer and writes it to disk, then you can see windows materialise in the files as they’re moved over the capturing program’s window.) Most users would find it is unacceptable for a application to get hold of a window but write over other windows when they overlap. Not only can a graphics resource be given to another application, but that resource might change and make pointers to it invalid (if a window is moved, for instance, or the virtual desktop panning thing kicks in).

Pointers will also stall the card, because suddenly the graphics card doesnt know what you are changing about the frame buffer.

Pointers are bad. But there might be alternatives.

This is just a wacky idea. Truly wacky. Freaked out. On drugs, man =) But what if there could be a pixel buffer extension which you COULD get the pointer to? That way you could write to memory on the video card (and it could be segregated from the frame buffer memory so the monitor doesn’t soak the read port on the chips all the time) in whatever format you wanted, just like system memory. Then you could use glDrawPixels from this memory into the frame buffer. it’d save on bus bandwidth because the data is already ON the card.

Well, this ought to do it for now.

Some final quick things i wanted to elaborate on, but can’t be bothered:

  • leaving it to the h/w is good. its abstraction. the h/w vendors can make improvements “behind your back”. This is exactly why object oriented languages have private member functions.

  • get over assembly. the days of hand optimising assembly code is dead. algorithmic optimisations are the way to go. balancing the pipeline for one processor is all very well and good, but what happens when you want to run your code on another processor? I mean, do you know ANYTHING about memory latencies, the number of pipeline stages, how superscalar the chip is (how many pipes it has, what set of instructions certain pipes have), how the branch prediction mechanism works, instruction timings and so on and so on. So, you spent 9 months of your life figuring thatout, and then someone brings out a new processor with more pipeline stages, and all that carefully balanced code is out the window.

  • and i disagree about coders writing FOR the h/w. they shouldn’t be writing to FIT h/w. [snipped]

cheers,
John

Read what john said. After that post, there’s really nothing more to say.

  • Matt

What do you mean, nothing else to say

Nicely said, John. You saved me from making a few points

About the idea of an accessible pixel buffer in video memory, I think that it still suffers from the format problems that you mention - what if it’s interlaced, etc. Although I think that it would work if this extension will be limited to certain formats that every card implementing it will have to support. This would of course not guarantee good performance, since the copy to the frame buffer would possibly be done by copying to main memory, changing the format, and writing back to the card. There’s sadly no way to guarantee that an OpenGL operation will be done purely in hardware.

I still think that reading and writing pixels using functions could work well, as long as the function doesn’t need to do conversion. Unfortunately, the only way to know what format has best performance is to hope that there’s documentation for a specific chip about that, and gear your routing for that chip. If you had such data for all chips, you could possibly find something that works decently well for all chips (my guess would be RGB 565 and RGBA 8888). Unfortunately AFAIK there’s no 565 internal format definition for textures (although GL_RGB5 will likely select this).

I think that some information from the chip makers would be helpful here. For example, while NVIDIA mentions the fastest formats for texture loading, there’s no information about the fastest way to read back the frame buffer. Although again I’d imagine that 565 and 8888 are good formats to use for 16 bit and 32 bit modes, respectively.

The fastest formats for reading back the different framebuffers are as follows:

16-bit color: GL_UNSIGNED_SHORT_5_6_5/GL_RGB
32-bit color: GL_UNSIGNED_BYTE/GL_BGRA

16-bit depth: GL_UNSIGNED_SHORT/GL_DEPTH_COMPONENT
32-bit depth/stencil: GL_UNSIGNED_INT_24_8_NV/GL_DEPTH_STENCIL_NV

If you want depth only, GL_UNSIGNED_INT/GL_DEPTH_COMPONENT and GL_UNSIGNED_SHORT/GL_DEPTH_COMPONENT are both all right. If you want stencil only, GL_UNSIGNED_BYTE/GL_STENCIL_INDEX is probably best.

DrawPixels is a bit trickier… I won’t get into it here.

  • Matt