Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: CL/GL Interop, OSX -- ever shared a Renderbuffer or Texture?

  1. #11

    Re: CL/GL Interop, OSX -- ever shared a Renderbuffer or Text

    Well, without posting at amd yet, it seems some people have problems in general if they do all the GL init first (create context, create fb, create & attach textures/renderbuffers, then create the CL context) -- which is what this program does. It would mess up compartmentalization a bit, but may be worth trying before asking, to create GL context then create CL context then make GL buffers....

    570/680 -- I've read so many discussions my head spins, mostly on the MacRumors board threads, so I'm probably confused. It's clear that the 680 is crippled in double-precision float performance, but hasn't become clear for me on single-precision. But it does kinda look like the 570 is the way to go with nVidia. Yes it is a pity that nV seem to be playing the pouty child with their CUDA vs "Open" CL.

    I was very excited about the GCN cards, but don't know when Apple will provide support. The GTX 5xx/6xx seem to work out of the box with 10.7.5 drivers. But, if the interop works on the 5870, it should be enough to do 33ms frames at 1024x768, which would be fine for now.

    (Far OT now, but that should be okay; the question has after all been answered and the thread is winding down with other info that may be of interest to a curious reader....)

  2. #12
    Senior Member
    Join Date
    Aug 2011
    Posts
    271

    Re: CL/GL Interop, OSX -- ever shared a Renderbuffer or Text

    Quote Originally Posted by Photovore
    Well, without posting at amd yet, it seems some people have problems in general if they do all the GL init first (create context, create fb, create & attach textures/renderbuffers, then create the CL context) -- which is what this program does. It would mess up compartmentalization a bit, but may be worth trying before asking, to create GL context then create CL context then make GL buffers....
    Hmm, I created the gl context first then the cl context.

    I had to do some weird stuff to get the gl context out of the glut-like stuff provided by JOCL though, and/or run the cl init in the glut.init() callback.

    570/680 -- I've read so many discussions my head spins, mostly on the MacRumors board threads, so I'm probably confused. It's clear that the 680 is crippled in double-precision float performance, but hasn't become clear for me on single-precision. But it does kinda look like the 570 is the way to go with nVidia. Yes it is a pity that nV seem to be playing the pouty child with their CUDA vs "Open" CL.
    Well nvidia seem to be 'crippled' on double for consumer cards in general. The 680 has more problems than that though for compute. I'm not sure a site called 'macrumours' should be your canonical source of information.

    I was very excited about the GCN cards, but don't know when Apple will provide support. The GTX 5xx/6xx seem to work out of the box with 10.7.5 drivers. But, if the interop works on the 5870, it should be enough to do 33ms frames at 1024x768, which would be fine for now.

    (Far OT now, but that should be okay; the question has after all been answered and the thread is winding down with other info that may be of interest to a curious reader....)
    Ahh vendor lockin - well that's your choice!

  3. #13

    Re: CL/GL Interop, OSX -- ever shared a Renderbuffer or Text

    Hmm, I created the gl context first then the cl context.
    Ok, but, did you create gl buffer objects before creating the cl context, or after? I do the gl context, then all gl buffer objects, then the cl context (due to original compartmentalization; all kernelish stuff is in one source file). But that could be a problem on AMD. From their board:

    "To use shared resources, the OpenGL® application must first create an OpenGL® context and then an OpenCL™ context. All resources created after the OpenCL™ context has been created can be shared between OpenGL® and OpenCL™. If resources are allocated before the OpenCL™ context is created, they cannot be shared between OpenGL® and OpenCL™." -- (user genaganna).

    ... though I'm a bit surprised that it fails at clCreateContext, before anything attempts to be shared. (Plus, it works fine on nV.)

    I'm not sure a site called 'macrumours' should be your canonical source of information.
    I _am_ sure you're right about that! ... but, it was attractive due to several threads (macos subpart) describing how to get the Fermi / Kepler cards to work on osx, with or without flashing. But, apparently they work in 10.7.5+ right out of the box.

    Ahh vendor lockin - well that's your choice!
    ... thinking ... oh, okay; you mean the fruit company....
    This project began over 20 years ago on mac os 7 or 8. Whereas I learn quickly and have written code for many architectures, it seemed the quickest path from old CodeWarrior was to stay on mac and force-learn Xcode, Cocoa, Objective-C and OpenCL; at least the system services might be familiar. But, it had been a very long time (it was still in CodeWarrior under SheepShaver up until 2011), and the apis had been superseded several times, so it may not have slowed the process down much to throw a new OS (linux?) onto the pile too. But also, I want to be able to spec a system to someone halfway around the world that will run this, so sticking to a major vendor and being able to name an OTC box might still have been a good idea. If I ever generate enough revenue to justify doing this full-time I may branch out; it might be wise to have more than one roost....

  4. #14
    Senior Member
    Join Date
    Aug 2011
    Posts
    271

    Re: CL/GL Interop, OSX -- ever shared a Renderbuffer or Text

    Quote Originally Posted by Photovore
    Hmm, I created the gl context first then the cl context.
    Ok, but, did you create gl buffer objects before creating the cl context, or after? I do the gl context, then all gl buffer objects, then the cl context (due to original compartmentalization; all kernelish stuff is in one source file). But that could be a problem on AMD. From their board:

    "To use shared resources, the OpenGL® application must first create an OpenGL® context and then an OpenCL™ context. All resources created after the OpenCL™ context has been created can be shared between OpenGL® and OpenCL™. If resources are allocated before the OpenCL™ context is created, they cannot be shared between OpenGL® and OpenCL™." -- (user genaganna).

    ... though I'm a bit surprised that it fails at clCreateContext, before anything attempts to be shared. (Plus, it works fine on nV.)
    Yeah i created the cl context first thing in the init callback. I only did some experiments and wasn't retro-fitting it to an existing application, which is a different kettle of fish. I probably started with an example which had already gone through working out various interop issues.

    If those are the requirements than I guess you have no option - at least it failing to create a context straight away tells you that you can't do that. It's probably some internal optimisation so that GL contexts and objects don't need to worry about OpenCL stuff unless you're trying to interoperate (or maybe it's just an internal hack to make it work, who knows?). Well at least you know how to tackle it.

    (I read the other comments but it's veering off topic a bit - but 20 years, well at least you'll be used to it by now

    I can't see any mention of this opengl requirement in the amd programming guide (appendix g), apart from the fact that the devices in the context must all be opengl-sharing compatible.

Page 2 of 2 FirstFirst 12

Similar Threads

  1. OpenGL / OpenCL interop with shared contexes and multithread
    By mado in forum Interoperability issues
    Replies: 2
    Last Post: 02-13-2013, 08:15 AM
  2. OpenCL - OpenGL 2D texture interop
    By majicou in forum OpenCL
    Replies: 4
    Last Post: 01-14-2012, 06:56 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •