tech-vector-ext@lists.riscv.org | Vector TG Meeting tomorrow

Home Messages Hashtags Subgroups

Date Date 1 - 5 of 5

Vector TG Meeting tomorrow

David Horner #665 I apparently missed the meeting that I thought was at noon eastern. There are of course the remaining open for v1.0 issues. I gather what was discussed was if we could reasonably move to public review without finalizing all of them. To the extent that addendums could be added, such as the table of "reserved" equivalent instructions, the usage section and the prior art section I agree that these could be added in parallel with the review. The other items I mentioned... imprecise intent wording... and the explanation of the encoding decisions.... both of these I think warrant a delay to have them in place for public consumption. toggle quoted message Show quoted text On Fri, Jul 9, 2021, 11:10 mark, <markhimelstein@...> wrote: just to qualify, I think we are talking about RVA22 (application target) and not RVM22 (microcontroller target). On Fri, Jul 9, 2021 at 8:07 AM Jan Wassenberg via lists.riscv.org <janwas=google.com@...> wrote: Mentioned by Krste in the meeting: processor profile already requires VLEN >= 128. On Fri, Jul 9, 2021 at 2:51 PM Jan Wassenberg via lists.riscv.org <janwas=google.com@...> wrote: A topic to discuss: lower bound on VLEN. The upper bound is helpful but even VL-agnostic code sometimes wants at least 128 bits. Example: N parallel instances of AES (16 bytes each), or N 128-bit results from 64x64 normal or carryless multiplication. We can get this already (assuming SEW_LMUL1MAX = 64) by setting LMUL=2, but it seems like a poor tradeoff that software should halve the number of registers/groups, just so that hardware could theoretically have single-element vectors. Can we mandate *VLEN >= 2SEW_LMUL1MAX, perhaps in a profile? That would help software :) BTW, are we intending to have the same binaries work on different implementations? It seems the only way to discover SEW_LMUL1MAX is to try various SEW/LMUL and check for vill. Because LMUL is baked into the intrinsic function name, software that wants portable binaries would have to recompile all vector code for LMUL=1,2,4,8, and then pick the first one that works. That's very burdensome, a profile guaranteeing SEW_LMUL1MAX = 64** or at least LMUL2MAX = 64 would also help a lot. On Fri, Jul 9, 2021 at 6:58 AM Krste Asanovic <krste@...> wrote: We’ll meet tomorrow to see if there are any remaining concerns before going Into public review, Krste
More All Messages By This Member
mark #664 just to qualify, I think we are talking about RVA22 (application target) and not RVM22 (microcontroller target). toggle quoted message Show quoted text On Fri, Jul 9, 2021 at 8:07 AM Jan Wassenberg via lists.riscv.org <janwas=google.com@...> wrote: Mentioned by Krste in the meeting: processor profile already requires VLEN >= 128. On Fri, Jul 9, 2021 at 2:51 PM Jan Wassenberg via lists.riscv.org <janwas=google.com@...> wrote: A topic to discuss: lower bound on VLEN. The upper bound is helpful but even VL-agnostic code sometimes wants at least 128 bits. Example: N parallel instances of AES (16 bytes each), or N 128-bit results from 64x64 normal or carryless multiplication. We can get this already (assuming SEW_LMUL1MAX = 64) by setting LMUL=2, but it seems like a poor tradeoff that software should halve the number of registers/groups, just so that hardware could theoretically have single-element vectors. Can we mandate *VLEN >= 2SEW_LMUL1MAX, perhaps in a profile? That would help software :) BTW, are we intending to have the same binaries work on different implementations? It seems the only way to discover SEW_LMUL1MAX is to try various SEW/LMUL and check for vill. Because LMUL is baked into the intrinsic function name, software that wants portable binaries would have to recompile all vector code for LMUL=1,2,4,8, and then pick the first one that works. That's very burdensome, a profile guaranteeing SEW_LMUL1MAX = 64** or at least LMUL2MAX = 64 would also help a lot. On Fri, Jul 9, 2021 at 6:58 AM Krste Asanovic <krste@...> wrote: We’ll meet tomorrow to see if there are any remaining concerns before going Into public review, Krste
More All Messages By This Member
Jan Wassenberg #663 Mentioned by Krste in the meeting: processor profile already requires VLEN >= 128. toggle quoted message Show quoted text On Fri, Jul 9, 2021 at 2:51 PM Jan Wassenberg via lists.riscv.org <janwas=google.com@...> wrote: A topic to discuss: lower bound on VLEN. The upper bound is helpful but even VL-agnostic code sometimes wants at least 128 bits. Example: N parallel instances of AES (16 bytes each), or N 128-bit results from 64x64 normal or carryless multiplication. We can get this already (assuming SEW_LMUL1MAX = 64) by setting LMUL=2, but it seems like a poor tradeoff that software should halve the number of registers/groups, just so that hardware could theoretically have single-element vectors. Can we mandate *VLEN >= 2SEW_LMUL1MAX, perhaps in a profile? That would help software :) BTW, are we intending to have the same binaries work on different implementations? It seems the only way to discover SEW_LMUL1MAX is to try various SEW/LMUL and check for vill. Because LMUL is baked into the intrinsic function name, software that wants portable binaries would have to recompile all vector code for LMUL=1,2,4,8, and then pick the first one that works. That's very burdensome, a profile guaranteeing SEW_LMUL1MAX = 64** or at least LMUL2MAX = 64 would also help a lot. On Fri, Jul 9, 2021 at 6:58 AM Krste Asanovic <krste@...> wrote: We’ll meet tomorrow to see if there are any remaining concerns before going Into public review, Krste
More All Messages By This Member
Jan Wassenberg #662 A topic to discuss: lower bound on VLEN. The upper bound is helpful but even VL-agnostic code sometimes wants at least 128 bits. Example: N parallel instances of AES (16 bytes each), or N 128-bit results from 64x64 normal or carryless multiplication. We can get this already (assuming SEW_LMUL1MAX = 64) by setting LMUL=2, but it seems like a poor tradeoff that software should halve the number of registers/groups, just so that hardware could theoretically have single-element vectors. Can we mandate *VLEN >= 2SEW_LMUL1MAX, perhaps in a profile? That would help software :) BTW, are we intending to have the same binaries work on different implementations? It seems the only way to discover SEW_LMUL1MAX is to try various SEW/LMUL and check for vill. Because LMUL is baked into the intrinsic function name, software that wants portable binaries would have to recompile all vector code for LMUL=1,2,4,8, and then pick the first one that works. That's very burdensome, a profile guaranteeing SEW_LMUL1MAX = 64** or at least LMUL2MAX = 64 would also help a lot. toggle quoted message Show quoted text On Fri, Jul 9, 2021 at 6:58 AM Krste Asanovic <krste@...> wrote: We’ll meet tomorrow to see if there are any remaining concerns before going Into public review, Krste
More All Messages By This Member
Krste Asanovic #660 We’ll meet tomorrow to see if there are any remaining concerns before going Into public review, Krste
More All Messages By This Member

1 - 5 of 5

1

Previous Topic Next Topic

Home Hashtags Subgroups Terms