Assortment of OpenCL fixes #139
Conversation
RSpliet
force-pushed
the
dev
branch
4 times, most recently
from
fb26cb2 to
ce01d53
Compare
|
Force-push updates "libopencl: Stub clGetProgramBuildInfo()" to include CL_API_SUFFIX__VERSION_1_0 and to use the provided macros rather than open-coding tedious data copies. |
RSpliet
force-pushed
the
dev
branch
2 times, most recently
from
009198e to
d748dce
Compare
|
And another update, this time pushing a v2 of d748dce "libopencl: Calculate a valid offset in bind_args()" to take into consideration alignment requirements. Sorry for having opened a pull request that has been a little WIP, I'm still advancing insights. From what I gather these should be good to merge now, although all feedback welcome! |
|
@tgrogers Ping? |
Assumes everything is ok, even if it isn't. Allows for some Rodinia benchmarks to fail slightly later. v2: Use available case macros. Signed-off-by: Roy Spliet <rs855@cam.ac.uk>
Signed-off-by: Roy Spliet <rs855@cam.ac.uk>
v2: Adhere to alignment requirements. v3: Small style fix. Signed-off-by: Roy Spliet <rs855@cam.ac.uk>
|
Force-push to rebase against current gpgpu-sim_distribution/dev head. Continuous integration testing is broken beyond my control. @aamodt Could you give me some indication whether you are open to third party contributions? I understand that people have agendas and lives, but 2.5 months of radio silence is a deterrent for collaboration. |
|
Hi,
Very sorry for the delay on this.
We will look into this now.
…Sent from my iPhone
On Oct 17, 2019, at 08:30, RSpliet ***@***.***> wrote:
Force-push to rebase against current gpgpu-sim_distribution/dev head. Continuous integration testing is broken beyond my control.
@aamodt Could you give me some indication whether you are open to third party contributions? I understand that people have agendas and lives, but 2.5 months of radio silence is a deterrent for collaboration.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
I am going to look into why the regression is failing it is not your code - something changed in the testbench code that has caused this issue. |
tgrogers
left a comment
tgrogers
left a comment
There was a problem hiding this comment.
This looks good to me.
Can are there some OpenCL test cases we can incorporate into our testing flow to ensure we don't break this functionality in the future?
I recall running some of the Rodinia benchmarks. Tomorrow at work I will rebase my working tree against your updated dev branch and verify. In my working tree there are some additional fixes and enhancements (some from my own hand, others cherry-picked from open pull requests, one from the just-closed PR #21 ) that may be required for Rodinia to work. The tidy commits live in my ocl-dev branch, but the unpolished one, referred to in part by issue #138 , might require some of your input before I'm happy to take that forward. Unfortunately, without a fix for #138, the OpenCL module doesn't even compile (well, link) neatly. |
Assortment of OpenCL fixes
2 participants
This pull request contain some of the clean fixes I performed to make OpenCL simulation work again in the current dev branch.
In addition to this, I worked around Issue #138 by simply defining no_of_ptx in opencl_runtime_api.cc . I didn't include this change in the pull request as I am unable to oversee the consequences of such a change.
Other changes not included but crucial for running OpenCL benchmarks again appear to be non-portable:
Similar non-portable changes might be required for anyone who wishes to test these patches in greater detail.