Does anyone know how to create a texture with a YUV colorspace so that we can get hardware based YUV to RGB colorspace conversion without having to use a fragment shader? I'm using an NVidia 9400 and I don't see an obvious GL extension that seems to do the trick. I've found examples how to use a fragment shader, but the project I'm working on currently only supports OpenGL 1.1 and I don't have time to convert it to 2.0 and perform all the regression testing necessary. This is also targeting Linux. On other platforms I've been using a MESA extension but it doesn't function on the Nvidia card.
Since you're okay with using extensions, but you're worried about going all-out with OpenGL 2.0, consider providing a simple fragment shader with the old-school ARB_fragment_program extension.
Alternatively, you could use a library like DevIL, ImageMagick, or FreeImage to perform the conversion for you.
the MESA extension you mention is for YCrCb ? If your nvidia card does not expose it, it means they did not expose the support for that texture format (it's the way to say the card supports it).
Your only option is to do the color conversion outside of the texture filtering block. (prior to submitting the texture data to GL, or after getting the values out of the texture filtering block)
GL can still help, as doing the linear transform is doable in GL1.1, provided you have the right extensions (dot3 texture combiner extension). That said, it's far from the panacea.
For what it's worth, the BINK implementation seems like it's doing the conversion with the CPU, using MMX (that's reading between the lines though). I would probably do the same, converting with SSE prior to loading to OpenGL. A CPU is fast enough to do this every frame.
Related
If I am currently developing a game for windows using SDL and GLEW (for OpenGL 3.0+) and I later want to port my game to Android, will I have to rewrite the majority of my code to convert from OpenGL 3.0 to OpenGL ES 2.0? Are there any programs that do this for me? Is it a big deal switching from OpenGL to OpenGL ES?
Not at all, it is very easy to convert.
Only differences are shader variables and constants, and suffixes like GL_RGBA8 to GL_RGBA8_OES. However, there are limits in OpenGL ES. For instance, you can use only GL_UNSIGNED_BYTE or GL_UNSIGNED_SHORT as indices data type GL_UNSIGNED_INT. Which means, you can not draw more than 65,535 indices at one go. It is not a big deal although you should refer to the official OpenGL ES manual, https://www.khronos.org/opengles/sdk/docs/man/
Refer to the link OpenGL ES 2.0 vs OpenGL 3 - Similarities and Differences by coffeeandcode
It really depends on your code
OpenGL ES 2.0 (and 3.0) is mostly a subset of Desktop OpenGL.
The biggest difference is there is no legacy fixed function pipeline in ES. What's the fixed function pipeline? Anything having to do with glVertex, glColor, glNormal, glLight, glPushMatrix, glPopMatrix, glMatrixMode, etc... in GLSL using any of the variables that access the fixed function data like gl_Vertex, gl_Normal, gl_Color, gl_MultiTexCoord, gl_FogCoord etc...
If you use any of those features you'll have some work cut out for you. OpenGL ES 2.0 and 3.0 are just plain shaders. No "3d" is provided for you. You're required to write all projection, lighting, texture references, etc yourself.
If you're already doing that (which most modern games probably do ) you might not have too much work. If on the other hand you've been using those old deprecated OpenGL features which from my experience is still very very common (most tutorials still use that stuff). Then you've got a bit of work cut out for you as you try to reproduce those features on your own.
There is an open source library, regal, which I think was started by NVidia. It's supposed to reproduce that stuff. Be aware that whole fixed function system was fairly inefficient which is one of the reasons it was deprecated but it might be a way to get things working quickly.
My project should greatly benefit from arbitrary/atomic read and write operations in a texture from glsl shaders. The Image load store extension is what I need. Only problem, my target platform does not support OpenGL 4.
Is there an extension for OGL 3 that achieves similar results? I mean, atomic read/write operations in a texture or shared buffer of some sort from fragment shaders.
Image Load Store and, especially atomic operations are features that must be backed up by specific hardware capabilities, that are very similar to features used in compute shaders. Only some of the GL3 hardware can handle it and only in a limited way.
Image Load Store in core profile since 4.2, so if your hardware (and driver) is capable of OpenGL 4.2, then you don't need any extensions at all
if your hardware (and driver) capabilities is lower than GL 4.2, but higher than GL 3.0, you can, probably, use ARB_shader_image_load_store extension.
quote: OpenGL 3.0 and GLSL 1.30 are required
obviously, not all 3.0 hardware (and drivers) will support this extension, so you must check for its support before use it
I believe, most NVIDIA GL 3.3 hardware supports it, but not AMD or Intel (that's my subjective observations ;) ).
If your hardware is lower than GL 4.2 and not capable of this extension, nothing really you can do. Just have an alternative code path with texture sampling and rendering to texture and no atomics (as I understood this is possible, but without "great benefit of atomic"), or simply report an error to those users, who not yet upgraded their rigs.
Hope it helps.
Is there a way to do a color conversion in OpenGL (e.g. from RGB to YUV420p back and forth)?
I can either use the contents of the back buffer, a texture or a FBO. I saw this question here, but is restricted to OpenGL 1.1, and I am not constrained to any particular version of OpenGL.
OpenGL Colorspace Conversion
I was wondering if there is a newer/faster way to do this with the newer versions. I would prefer not to use anything that is hardware specific, but if it needs to be, I am working with Nvidia GPUs.
Since you want newer/faster, yes you can try using CUDA or OpenCL. Whether they will be much faster than a shader... I have no idea, do let us know. If anything, it gives you more control on how resources are allocated to the task.
Both frameworks have ways of sharing memory with OpenGL so you should be able to just write a kernel and pass it your opengl texture/fbo.
I happen to have written a number of such modules for xpra, you can find links for them here: xpra wiki: CSC (code is GPL2+)
By this I mean, does Cairo draw lines, shapes and everything using opengl acelerated primitives or no? and if not, a library that does this?
The OpenGL backend certainly accelerates some functions. But there are many it can't accelerate. The fact that it's written against GL 2.1 (and thus can't use more advanced features of 3.x or 4.x hardware) means that there is a lot that it simply cannot accelerate.
If you are willing to limit yourself to NVIDIA hardware, NVIDIA just came out with the NV_path_rendering extension, which provides a lot of the 2D functionality you would find with Cairo. Indeed, it's possible that you could write a Cairo backend for it. The path rendering extension is only available on GeForce 8xxx hardware and above.
It's nifty in that it's focused on the vertex pipeline. It doesn't do things like gradients or colors or whatever. That's good, because it still allows you the use of a fragment shader. Which means you get to do pretty much whatever you want ;)
Cairo is designed to have a flexible backend for rendering. It can use OpenGL for rendering, though support is still listed as "experimental" at this point. For details, see using cairo with OpenGL.
It can also output to the X Window System, Quartz, Win32, image buffers, PostScript, PDF, and SVG, and more.
I don't know whether this is the right forum. Anyway here is the question. In one of our application we display medical images and on top of them some algorithm generated bitmap. The real bitmap is a 16bit gray scale bitmap. From this we generate a color bitmap based on a look up table for eg
(0-100)->green
(100-200)->blue
(200>above)->red
The display is working well and good with small images 256x256. But when the display area becomes big say 1024x1024 the gray scale to color bitmap conversion takes a while and the interactions are not smooth any more. In the recent times I have heard a lot about general purpose GPU programming. In our deployment we have high end (Nvidia QuadroFX) graphics card.
Our application is built using .Net/C# if requiured I can add little bit of C++/CLI too.
Now my question is can this bitmap conversion be offloaded to the graphics processor? Where should I look for further reading?
Yes -- and since you're (apparently) displaying the bitmap, you don't need to go the GPGPU route (e.g., OpenCL or CUDA). You can use a programmable shader for it -- and if I understand what you're saying, it'll be a pretty straightforward one at that.
As far as how to write the shader, it will depend (mostly) on how you're doing the rest of your drawing. Just for an obvious example, if you're already using WPF for your drawing, you'll probably want to use an HLSL shader (WPF supports pixel shaders fairly directly).
It's probably also worth noting that if you had to support older hardware, a table lookup like this is something you could actually manage pretty easily on the GPU, even without programmable shaders. As long as you only need to support recent hardware, a shader will probably be simpler though.