Open GarveyJoe opened 1 year ago
I don't have assignment privileges. Can this be assigned to @rrzeszut?
Can this be assigned to @rrzeszut?
Looks like no, GitHub UI doesn't show that account even if I copy the name. Probably some extra permissions within the repo are needed for that
@justin-rosner, do you own pipes now? 1 and 2 from this list have yet to be addressed. Also, there was one other concern that Rob was aware of but wasn't on this tracker; I'll add it as number 9 and cross out the addressed ones.
@justin-rosner, do you own pipes now? 1 and 2 from this list have yet to be addressed. Also, there was one other concern that Rob was aware of but wasn't on this tracker; I'll add it as number 9 and cross out the addressed ones.
I do own pipes now. I'll take a look at this.
I couldn't get the strikethrough to format nicely with the quotes, but 3-8 have been addressed in this PR: https://github.com/intel/llvm/commit/2a091189209f47235383700c1dca96461729a520
The current pipes extension specs (https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/supported/sycl_ext_intel_dataflow_pipes.asciidoc and https://github.com/intel/llvm/pull/9027/files?short_path=e64b9f7#diff-e64b9f7634f7f2218305a6811bcf87686e3cac717238065a83f8d74f227b3c7a) have several issues related to the experimental properties that should be cleaned up. These are the issues I see:
This should say "properties" or "properties object". "Property list" is a class defined in the core SYCL spec that can't convey properties at compile time.
I believe the intent is to say that the compiler is allowed to optimize the pipe if points endpoints are visible to it. But by omitting those crucial words it sounds like we're saying that the compiler is allowed to ignore the annotation if both endpoints are visible side-effects of the program, i.e. if they aren't visible to the compiler. I think it would be cleaner to drop this sentence entirely.
The bits_per_symbol value needs to evenly divide the data type size, not the other way around.
ready_latency and bits_per_symbol are encoded as signed integers but are restricted to unsigned values. It would probably be cleaner to use unsigned integers.
Why must min_capacity be 0 for a pipe with uses_valid = false?
It doesn't make sense to lump the presence/absence of a ready signal into the protocol property but not do the same for the valid signal given that they are two sides of the same coin. Either both should be part of the protocol property of neither should be.
ready_latency is a property of avalon-st but not avalon-mm. What happens if I set it when the protocol is avalon_mm or avalon_mm_uses_ready. This and the previous point make me think we need to re-think how these properties interact with protocol.
The avalon_mm property doesn't make sense because when using a shared CSR, the protocol can't be decided on a pipe-by-pipe basis. There's only one shared CSR in such cases and as such its protocol is a device-image-level decision. As such, that property would be better renamed something to the effect of "shared CSR". We should make sure to align on this name across all things that can be accessed through the CSR (device globals, kernel arguments, kernel controls).