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

Allow multiple inner products with the same vector in one kernel #32

Closed
karlrupp opened this issue May 31, 2013 · 6 comments
Closed

Allow multiple inner products with the same vector in one kernel #32

karlrupp opened this issue May 31, 2013 · 6 comments
Assignees
Milestone

Comments

@karlrupp
Copy link
Collaborator

Required for some flavors of GMRES.

@ptillet
Copy link
Collaborator

ptillet commented May 31, 2013

This shouldn't be a problem. However, we need to fully specify an upper
limit on the number of inner products that can be packed together,
considering each new inner product induces register pressure and local
memory usage :P

2013/5/31 Karl Rupp notifications@github.com

Required for some flavors of GMRES.


Reply to this email directly or view it on GitHubhttps://github.com//issues/32
.

@karlrupp
Copy link
Collaborator Author

Some time ago I implemented this for up to 8 different vectors (outside ViennaCL). Higher counts just repeatedly call these kernels then. Works like a charm :-)

@ghost ghost assigned ptillet Jun 1, 2013
@ptillet
Copy link
Collaborator

ptillet commented Jun 8, 2013

I prepared the field to handle dual-kernels with multiple operations. However, I am realizing packing multiple inner products together can only be done if there is no dependency. How/Where to check the dependency between operations? This should actually be a distinct tool, almost independent from the generator (since it may also be used in the scheduler or multi-devices)...

@karlrupp
Copy link
Collaborator Author

karlrupp commented Jun 8, 2013

I'd prefer to check this in the scheduler logic. Thus, I'd like to have a 'no aliasing can be assumed' policy for the generator, because this makes this way the generator can really focus on performance without having to do too much bookkeeping. The alias checking is much better done by a scheduler logic on top of the generator.

@ptillet
Copy link
Collaborator

ptillet commented Jun 8, 2013

Awesome ! This makes my life much much easier if independent operations are in independent custom operations!

@karlrupp
Copy link
Collaborator Author

Implementation completed here:
0a1e5c9

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

No branches or pull requests

2 participants