END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

I've been recently learning OpenCL and I've been using OpenGL for a while.

I have this one program I recently posted about that I want to make run on the GPU
http://www.fractalforums.com/index.php?action=gallery;sa=view;id=20076

What's the fastest way to write directly to pixels (no rasterization)?

Is it fastest to just use SDL and write to pixels from the CPU like my program already does?

You may also want to implement a fallback method that copies via the CPU, for OpenCL devices that don't support OpenGL sharing (for example, for testing on machines with very good CPU but not-so-good GPU).

Well actually CUDA is great, it has a lot of extra features much sooner than OpenCL and obviously it works really well on Nvidia devices because of their early and strong push, but AMD make awesome GPUs too (and Intel's iGPU is pretty great in many ways), so it's basically unacceptable not to be able to use them with the same language / API.

Besides that, I actually like how OpenCL is structured, and if Nvidia+Apple ever get around to supporting OpenCL 2.0 it will be a glorious, glorious day. Apple is the biggest offender here, for heading the OpenCL consortium and then (deliberately?) abandoning it for their Metal API; it really smacks of subterfuge. Google need to get off their asses and make it standard in Android, too.

To be honnest i don't care much about interoperability, i use openCL because i find it easier to use than cuda
CUDA have more feature but i don't understand them 
Apple is the new microsoft, don't expect anything but proprietary clusterf*ck
By the way, anyone tried Vulkan ?

About the original question : i don't do it.
I do the heavy computation on GPU, then move it back to CPU to eventually do some more stuff and let the whatever api/library i'm using do the drawing in an old fashioned way.
Unless you do some high FPS / low latency stuff (which you probably don't if you're computing fractal) it doesn't matter much performance-wise.

That's exactly right.

Your bump has reminded me that since I first posted this thread I think I figured out the answers to my original problem. I'll elaborate here on what I found in case anybody gets here from Google:

To get the performance gains from a GPU when you want to make something fast and pixelwise, you can't do it per pixel (operate on the integer coordinates of the screen). That's kind of an antiquated way of doing things. GPUs are designed to work with floating point values and are better at computing things to go on the screen.

To make it work, you set up OpenGL so that there is a rectangle directly in front of the screen.

Then you can just compute your ray tracer, fractal, etc. off of the interpolated coordinates that OpenGL will give you in the frag shader.

You don't get to operate off of the integer pixel coordinates and return RGB values if you want to be fast because floats are the language of the GPU!

My error when I posted this thread was trying to avoid rasterization to go fast.

The trick is to think of the screen as continuous during your computation (which is done in your shader program) and let OpenGL rasterize it for you.

Really fragments are pixels when you are just looking at a rectangle that is parallel to your screen in an orthogonal projection (I.e., the lack of a projection.)

Floats are the language of the GPU!