Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimum version macros #54

Merged
merged 1 commit into from
Sep 6, 2014
Merged

Minimum version macros #54

merged 1 commit into from
Sep 6, 2014

Conversation

vchuravy
Copy link
Member

This PR adds minimum version macros as discussed in #42, #49 and #40 based on a runtime check and caching of the result in a global dictionary.

They take the form of a ternary operator:

# E can be a variable of type Context, CmdQueue, Platform or Device
@min_v12 E begin 
    ....
end : error("Only supported since OpenCL 1.2")

to see how this might be used take a look at the branch https://github.com/JuliaGPU/OpenCL.jl/tree/vc/refactor_version_dependent_code

@jakebolewski
Copy link
Member

This looks great. I think that this is a much simpler design. The only thing I would add is a finalizer hook to unregister the object pointer from the dict when it is gc'd.

@vchuravy
Copy link
Member Author

vchuravy commented Sep 2, 2014

Hm, when I add a finalizer I get the following error:

function check_version(elem, version :: VersionNumber)
    id = _get_id(elem)
    version <= get!(_versionDict, id) do
        finalizer(id, key -> delete!(_versionDict, key))
        opencl_version(elem)
    end
end
 objects of type Ptr{None} cannot be finalized

@jakebolewski
Copy link
Member

The hook would included in the Platform, CmdQueue, etc object finalizers. The extra step would see if the object being finalized has an id in the dict and remove itself before returning.

@vchuravy
Copy link
Member Author

vchuravy commented Sep 2, 2014

But if you have two objects that reference to the same device/platform you would remove an entry unnecessarily. There is only a limited number of devices and platforms on the system so those shouldn't be a problem. The only object that would need a finalizer call would be Context since CmdQueue uses the id of the associated Device

@jakebolewski
Copy link
Member

If two objects reference the same context pointer then one will not retain the context. The context object would only remove itself from the dict if it owns the underlying pointer.

@vchuravy
Copy link
Member Author

vchuravy commented Sep 5, 2014

@jakebolewski like so?

This was referenced Sep 5, 2014
@jakebolewski
Copy link
Member

@vchuravy exactly. The only other comment I have is that pointer should be defined so it may be cleaner to replace _get_id with pointer(CLObject).

@vchuravy
Copy link
Member Author

vchuravy commented Sep 5, 2014

@jakebolewski I agree that is certainly cleaner. I will then squash this and merge it.

Maybe we should also introduce and abstract type CLObject as a supertype of CmdQueue, Device, Context, and Platform so that one could dispatch opencl_version and check_version on it.

 - Since Contexts and CmdQueues are created en masse we need to cleanup after them.
@jakebolewski
Copy link
Member

Cool, all OpenCL objects sharing a common abstract subtype makes sense. We
could then get rid of the equality macro.

On Fri, Sep 5, 2014 at 1:49 PM, Valentin Churavy [email protected]
wrote:

@jakebolewski https://github.com/jakebolewski I agree that is certainly
cleaner. I will then squash this and merge it.

Maybe we should also introduce and abstract type CLObject as a supertype
of CmdQueue, Device, Context, and Platform so that one could dispatch
opencl_version and check_version on it.


Reply to this email directly or view it on GitHub
#54 (comment).

vchuravy added a commit that referenced this pull request Sep 6, 2014
@vchuravy vchuravy merged commit 80983d7 into master Sep 6, 2014
@vchuravy vchuravy deleted the vc/version_api branch September 6, 2014 17:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants