Date   

Re: Zve should be a strict subset of V, use new option to relax VLEN

Bill Huffman
 

Hi Krste,

The descriptions of Zvl* look good. A couple of comments:

* The V description says vector length greater than or equal to 128. Should it instead refer to Zvl128b?

* I wonder if there could be a table for what Zve* and V include in instructions with both YES and NO on appropriate lines of the table for what each extension must include. The statements, understandably, include what instructions are supported. But I have trouble with the process-of-elimination to see what's not included as well as with the comparison of Zve to V.

Bill

-----Original Message-----
From: tech-vector-ext@lists.riscv.org <tech-vector-ext@lists.riscv.org> On Behalf Of Krste Asanovic
Sent: Thursday, July 15, 2021 3:03 AM
To: Bill Huffman <huffman@cadence.com>
Cc: Guy Lemieux <guy.lemieux@gmail.com>; tech-vector-ext@lists.riscv.org
Subject: Re: [RISC-V] [tech-vector-ext] Zve should be a strict subset of V, use new option to relax VLEN

EXTERNAL MAIL



I added vector length extensions to spec.

Please review,

Krste

On Mon, 12 Jul 2021 14:31:07 +0000, "Bill Huffman" <huffman@cadence.com> said:
| Hello Guy,
| It definitely would be good for Zve to be a strict subset of V. I
| think that means the same thing as that any binary that runs on Zve will run correctly on Z. But I’m not seeing how any code that runs on a Zve compliant core with VLEN < 128 will fail to run on V. Do you have an example? Is there a further relaxation that I’m not thinking about besides VLEN < 128?

| Separately, I don’t think we can add an option that restricts. All code that will run without an option should run with the option. But I think V may be able to be a superset without that.

| Bill

| From: tech-vector-ext@lists.riscv.org
| <tech-vector-ext@lists.riscv.org> On Behalf Of Guy Lemieux
| Sent: Monday, July 12, 2021 7:29 AM
| To: tech-vector-ext@lists.riscv.org
| Subject: [RISC-V] [tech-vector-ext] Zve should be a strict subset of
| V, use new option to relax VLEN

| EXTERNAL MAIL

| Hi,

| The way 18.1 and 18.2 currently read in the V spec is a bit confusing.

| It defines Zve as "Vector extensions for Embedded Processors", and V as a "Vector Extension for Application Processor".

| 1) Processors vs Processor?

| 2) It appears the Zve extension relaxes VLEN rules which are not supported by V. This appears to be the only change that prevents Zve from being a strict subset of V.

| 3) I think Zve should be a strict subset of V. The relaxation of VLEN
| should be an option that can be added to Zve or V. Some AP may wish to remain code-compatible with Zve, and this will make things more clear. This will clarify code generation and aid compatibility. Perhaps call this option Zvlen?

| 4) If there are other differences that I've missed in (3), they should be similarly separated.

| Thank you,

| Guy

|


Re: Zve should be a strict subset of V, use new option to relax VLEN

Krste Asanovic
 

I added vector length extensions to spec.

Please review,

Krste

On Mon, 12 Jul 2021 14:31:07 +0000, "Bill Huffman" <huffman@cadence.com> said:
| Hello Guy,
| It definitely would be good for Zve to be a strict subset of V. I think that means the same thing as that any binary that runs on Zve will run correctly on Z. But I’m not seeing how any code that
| runs on a Zve compliant core with VLEN < 128 will fail to run on V. Do you have an example? Is there a further relaxation that I’m not thinking about besides VLEN < 128?

| Separately, I don’t think we can add an option that restricts. All code that will run without an option should run with the option. But I think V may be able to be a superset without that.

| Bill

| From: tech-vector-ext@lists.riscv.org <tech-vector-ext@lists.riscv.org> On Behalf Of Guy Lemieux
| Sent: Monday, July 12, 2021 7:29 AM
| To: tech-vector-ext@lists.riscv.org
| Subject: [RISC-V] [tech-vector-ext] Zve should be a strict subset of V, use new option to relax VLEN

| EXTERNAL MAIL

| Hi,

| The way 18.1 and 18.2 currently read in the V spec is a bit confusing.

| It defines Zve as "Vector extensions for Embedded Processors", and V as a "Vector Extension for Application Processor".

| 1) Processors vs Processor?

| 2) It appears the Zve extension relaxes VLEN rules which are not supported by V. This appears to be the only change that prevents Zve from being a strict subset of V.

| 3) I think Zve should be a strict subset of V. The relaxation of VLEN should be an option that can be added to Zve or V. Some AP may wish to remain code-compatible with Zve, and this will make
| things more clear. This will clarify code generation and aid compatibility. Perhaps call this option Zvlen?

| 4) If there are other differences that I've missed in (3), they should be similarly separated.

| Thank you,

| Guy

|


Vector TG Meeting Minutes 2021/07/09

Krste Asanovic
 

Date: 2021/07/09
Task Group: Vector Extension
Chair: Krste Asanovic
Vice-Chair: Roger Espasa
Number of Attendees: ~12
Current issues on github: https://github.com/riscv/riscv-v-spec

We had a short meeting to uncover any remaining issues with the spec
before public review. There were no new issues raised.

We discussed mechanics of public review process. The spec will have
final edits made to close of remaining clarifications then be sent
out for public review.


Re: Zve should be a strict subset of V, use new option to relax VLEN

Bill Huffman
 

Hello Guy,

 

It definitely would be good for Zve to be a strict subset of V.  I think that means the same thing as that any binary that runs on Zve will run correctly on Z.  But I’m not seeing how any code that runs on a Zve compliant core with VLEN < 128 will fail to run on V.  Do you have an example?  Is there a further relaxation that I’m not thinking about besides VLEN < 128?

 

Separately, I don’t think we can add an option that restricts.  All code that will run without an option should run with the option.  But I think V may be able to be a superset without that.

 

      Bill

 

From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Guy Lemieux
Sent: Monday, July 12, 2021 7:29 AM
To: tech-vector-ext@...
Subject: [RISC-V] [tech-vector-ext] Zve should be a strict subset of V, use new option to relax VLEN

 

EXTERNAL MAIL

Hi,

 

The way 18.1 and 18.2 currently read in the V spec is a bit confusing.

 

It defines Zve as "Vector extensions for Embedded Processors", and V as a "Vector Extension for Application Processor".

 

1) Processors vs Processor?

 

2) It appears the Zve extension relaxes VLEN rules which are not supported by V. This appears to be the only change that prevents Zve from being a strict subset of V.

 

3) I think Zve should be a strict subset of V.  The relaxation of VLEN should be an option that can be added to Zve or V. Some AP may wish to remain code-compatible with Zve, and this will make things more clear. This will clarify code generation and aid compatibility. Perhaps call this option Zvlen?

 

4) If there are other differences that I've missed in (3), they should be similarly separated.

 

Thank you,

Guy


Zve should be a strict subset of V, use new option to relax VLEN

Guy Lemieux
 

Hi,

The way 18.1 and 18.2 currently read in the V spec is a bit confusing.

It defines Zve as "Vector extensions for Embedded Processors", and V as a "Vector Extension for Application Processor".

1) Processors vs Processor?

2) It appears the Zve extension relaxes VLEN rules which are not supported by V. This appears to be the only change that prevents Zve from being a strict subset of V.

3) I think Zve should be a strict subset of V.  The relaxation of VLEN should be an option that can be added to Zve or V. Some AP may wish to remain code-compatible with Zve, and this will make things more clear. This will clarify code generation and aid compatibility. Perhaps call this option Zvlen?

4) If there are other differences that I've missed in (3), they should be similarly separated.

Thank you,
Guy


Re: Vector TG Meeting tomorrow

David Horner
 

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.

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 >= 2*SEW_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







Re: Vector TG Meeting tomorrow

mark
 

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 >= 2*SEW_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







Re: Vector TG Meeting tomorrow

Jan Wassenberg
 

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 >= 2*SEW_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







Re: Vector TG Meeting tomorrow

Jan Wassenberg
 

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 >= 2*SEW_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







Re: Vector TG Meeting tomorrow - imprecise trap description/use.

David Horner
 

For discussion:

The text states:

Imprecise traps are primarily intended to be used in situations where
reporting an error and terminating execution is the appropriate response.

Issue #598 to be resolved after v1.0 and issue #364 which is tagged with "resolve for v1.0" are inconsistent with the idea that imprecise traps are primarily for abort situations.

The broad range of "imprecise traps" lends itself to defining many states that are compatible with OS management even in a multitasking environment.

We should keep this door substantially open.


On 2021-07-09 12:57 a.m., Krste Asanovic wrote:
We’ll meet tomorrow to see if there are any remaining concerns before going Into public review,
Krste





Vector TG Meeting tomorrow

Krste Asanovic
 

We’ll meet tomorrow to see if there are any remaining concerns before going Into public review,
Krste


Re: Vector TG meeting minutes 2021/07/02

Bill Huffman
 

 

 

-----Original Message-----
From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Krste Asanovic
Sent: Friday, July 2, 2021 12:53 PM
To: tech-vector-ext@...
Subject: [RISC-V] [tech-vector-ext] Vector TG meeting minutes 2021/07/02

 

EXTERNAL MAIL

 

 

 

Date: 2021/07/02

Task Group: Vector Extension

Chair: Krste Asanovic

Vice-Chair: Roger Espasa

Number of Attendees: ~12

Current issues on github: https://urldefense.com/v3/__https://github.com/riscv/riscv-v-spec__;!!EHscmS1ygiU1lA!RMBBi1gNhOHzOU2abQmClNEMWkaI2-aaN2062y7AMPrW99eX1JSWR8QC9lFNZlI$

 

We discussed several issues that will result in clarifications to the current spec, but no substantive changes.  The plan is to release a

v1.0-rc2 next week, then have a (hopefully) final meeting next week before releasing for public review.

 

#701 Whole register mask loads

 

The group revisited the decision to exclude these from the v1.0 spec.

The discussion concluded that the use was narrow (code that knew the target register would be used as a mask, but where vector length was different than current vector length), and that the effect could be synthesized with a four instruction sequence to save vl, set max vector length, then use mask load, then restore vl (in some cases, a portion of the vl manipulation could possibly be amortized with other code).  The decision was to continue to exclude these from v1.0 and the spec commentary will be updated to describe the alternative code sequence.

 

I think having the exact instruction sequence will both help clarify support for wide, re-organizing datapaths and ensure that the envisioned sequence isn't only 99% correct.

 

#702 Reductions when vl=0

 

The group discussed the behavior of reductions when vl=0, and concluded we'd retain the current definition.  This only affects the case where the source and destination scalar are in different vector registers, which was determined to be a rare case that would often be known statically in code.  Commentary will be added to text to provide rationale.

 

Not just the rational but what cases need particular care to avoid unexpected behavior.

 

     Bill

 

#703 Clarify that vl=0 does not affect moves from vector registers

 

After reviewing #702, it was realized the current text could be confusing for the effect of vl=0 on vector->scalar move instructions, so the text will be clarified.

 

#704 Add vector memory operations to RISC-V MCM

 

As already noted in spec, a more formal definition of vector memory operations interaction with MCM is needed.

 

#705 Vector memory operations under TSO.

 

While not necessary for v1.0 (as Ztso is still not ratified, though frozen), the group realised that the behavior under RVTSO needs to be clarified.

 

#664 drop tail undisturbed

 

This closed issue was raised again.  The group agreed that tail undisturbed caused implementation complexity for renamed/OoO implementations, but also acknowledged there were some important use cases for tail undisturbed.  The observation was made that the complexity for renamed/OoO machines mostly arises from optimizing for performance, so implementations that did not care about tail-undisturbed use cases could simplify microarchitecture.  A note will be added explaining this tradeoff.

 

 

 

 

 

 

 

 

 


Vector TG meeting minutes 2021/07/02

Krste Asanovic
 

Date: 2021/07/02
Task Group: Vector Extension
Chair: Krste Asanovic
Vice-Chair: Roger Espasa
Number of Attendees: ~12
Current issues on github: https://github.com/riscv/riscv-v-spec

We discussed several issues that will result in clarifications to the
current spec, but no substantive changes. The plan is to release a
v1.0-rc2 next week, then have a (hopefully) final meeting next week
before releasing for public review.

#701 Whole register mask loads

The group revisited the decision to exclude these from the v1.0 spec.
The discussion concluded that the use was narrow (code that knew the
target register would be used as a mask, but where vector length was
different than current vector length), and that the effect could be
synthesized with a four instruction sequence to save vl, set max
vector length, then use mask load, then restore vl (in some cases, a
portion of the vl manipulation could possibly be amortized with other
code). The decision was to continue to exclude these from v1.0 and
the spec commentary will be updated to describe the alternative code
sequence.

#702 Reductions when vl=0

The group discussed the behavior of reductions when vl=0, and
concluded we'd retain the current definition. This only affects the
case where the source and destination scalar are in different vector
registers, which was determined to be a rare case that would often be
known statically in code. Commentary will be added to text to provide
rationale.

#703 Clarify that vl=0 does not affect moves from vector registers

After reviewing #702, it was realized the current text could be
confusing for the effect of vl=0 on vector->scalar move instructions,
so the text will be clarified.

#704 Add vector memory operations to RISC-V MCM

As already noted in spec, a more formal definition of vector memory
operations interaction with MCM is needed.

#705 Vector memory operations under TSO.

While not necessary for v1.0 (as Ztso is still not ratified, though
frozen), the group realised that the behavior under RVTSO needs to be
clarified.

#664 drop tail undisturbed

This closed issue was raised again. The group agreed that tail
undisturbed caused implementation complexity for renamed/OoO
implementations, but also acknowledged there were some important use
cases for tail undisturbed. The observation was made that the
complexity for renamed/OoO machines mostly arises from optimizing for
performance, so implementations that did not care about
tail-undisturbed use cases could simplify microarchitecture. A note
will be added explaining this tradeoff.


Vector TG meeting tomorrow usual time slot

Krste Asanovic
 

Based on feedback, we'll have a vector TG meeting tomorrow to address
concerns. Details in usual place in Google calendar,

Krste


Re: Smaller embedded version of the Vector extension

Guy Lemieux
 

I’ve taken a stab at reducing the number of instructions in my RVV-lite proposal. The overriding goal, in my mind, is to preserve forward software compatibility so the ecosystem doesn’t need to fragment.

There are lots of instructions that are not essential which I have eliminated. Also, I have dropped or limited the scope of the widening and narrowing instructions — they are awkward to implement because they change the demand in register file read or write bandwidth
due to a mixing of data element sizes.

Limiting LMUL is far more difficult, because it is fundamental to the way RVV changes data widths. The best I could do in my proposal is require SEW/LMUL to always be 8.

I’m happy to share my proposal on request, but I’ve not broadcast it here because it still needs more work. I’d welcome any thoughts on improving it though.

Guy



On Sun, Jun 27, 2021 at 11:54 PM Gregory Kielian <gkielian@...> wrote:
Hi Everyone, wanted to continue this interesting discussion.


Was wondering if this is a complete listing of the requirements (so far) for the ZVE* extensions? or if there might be another document/spreadsheet/source-file which would have a running-list of requirements?

In particular, hoping to check if there might be a running-list of instructions required by the ZVE* extensions (e.g. if we would need to implement vector integer division) and the range of LMUL levels we would be required to support?

Looking forward to continuing the discussion.

All the best,
Gregory



Re: Smaller embedded version of the Vector extension

Gregory Kielian
 

Hi Everyone, wanted to continue this interesting discussion.


Was wondering if this is a complete listing of the requirements (so far) for the ZVE* extensions? or if there might be another document/spreadsheet/source-file which would have a running-list of requirements?

In particular, hoping to check if there might be a running-list of instructions required by the ZVE* extensions (e.g. if we would need to implement vector integer division) and the range of LMUL levels we would be required to support?

Looking forward to continuing the discussion.

All the best,
Gregory


Re: No vector TG meeting tomorrow - preparing to start public review

Bill Huffman
 

I did not expect that this meeting, of all meetings, would be cancelled.

 

So I’ll send my comments by email now rather than discussing an important one at the meeting and filing issues for minor ones.  I think #1 is important.  The rest are lesser comments:

  1. I’m (still) concerned about the lack of a whole register load with “mask” type hint.  I think leaving it out damages the clarity of support for micro-architectural redistribution, which is critical for wide SIMD.
    • If we really will not add the instruction, I’m thinking there’s a relatively simple sequence that does the job, like save vl, set it to max, do an ordinary mask load, restore vl.  Could you add that sequence somewhere.  Maybe in the note about not having the mask version.  That would help make the completeness of support clear for micro-architectural redistribution.
  2. In Section 3.5, I’m not sure why vlenb must be a design-time constant.  An implementation could vary it as a mode.  So, I think the wording should allow that.
  3. Section 13.19 has a typo.  It says “widening” when I think it means “narrowing.”
  4. In Section 14, what is the thinking on why there’s no update of the destination of reductions when vl=0?  I can’t see any reason not to update – it seems easier to update – and it could, in some circumstances matter.  This rule means that code has to ensure that it does not execute a reduction in a rare case that vl might be zero unless the source scalar and destination scalar are the same register.  Why require that?
  5. In Section 7.8, I thought we wanted the set of registers a segment load/store could access to be limited to an aligned group of eight to allow optimizations on the renaming of registers.  So a three register group could start at register #3, for example.  But here it says that a sequence can start anywhere.

 

    Bill

 

From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Krste Asanovic
Sent: Friday, June 25, 2021 3:41 AM
To: tech-vector-ext@...
Subject: [RISC-V] [tech-vector-ext] No vector TG meeting tomorrow - preparing to start public review

 

EXTERNAL MAIL

There have been no substantial objections raised on the v1.0-rc1 draft, so I will cancel the meeting tomorrow.

There are some minor suggestions and edits (thank you!), and I will incorporate these into the v1.0 version which we’ll freeze for public review, hopefully starting in a day or at most a few days.

Remember, you can still comment during public review.

Krste

 


Re: No vector TG meeting tomorrow - preparing to start public review

David Horner
 

I am disappointed that the meeting was cancelled.

I am concerned that jnk0le's contributions/concerns, in particular, have been dismissed and to the extent that they were objections to the draft have been categorized as not substantial.

The meeting  was a final verification/certification opportunity. A ratification of sorts.

I have found our meetings productive and collectively raised concerns and insights that have improved the V extension and its documentation.

I intended to raise some concerns that are difficult to express as an "issue" and hoped to get the groups input more dynamically.

Given the meeting is cancelled, I will type these in as best I can as issues.

I apologize that I did not anticipate the cancellation of the meeting, and thus that I let my life interfere  with providing these concerns as issues.

[Our son suddenly was at the top of the waiting list for long term care placement, which means in Ontario that you drop everything to make it work. And further, with covid restrictions we needed to ensure, on admission, he has completely set up as he is now quarantined for 14 day. Also that  they messed up his medication and I spent the better part of a day, and the night it happened, getting that corrected. He has Dopamine Responsive Dystonia and takes levo/carbadopaCR and pramipexole. Thus, they thought he has Parkinsons and concentrated his medications to daytime hours, leaving him without his medication for 12 hours over night. It took a full 36 hours before he was stabilized and free of adverse effects. And this is happening on the background of us selling our house, downsizing, moving, new rental accommodation set up and shut off old services and legal matters, including document preps and signing papers. Once again, I apologize, I know of others in worse constraints that are on the lists etc. 24/7. So it is just me, given others can contribute when their life is hectic.]


Contributing during public review does not prepare the document for public consumption. I believe cancelling the meeting is a lost opportunity to do that.



On 2021-06-25 3:40 a.m., Krste Asanovic wrote:
There have been no substantial objections raised on the v1.0-rc1 draft, so I will cancel the meeting tomorrow.

There are some minor suggestions and edits (thank you!), and I will incorporate these into the v1.0 version which we’ll freeze for public review, hopefully starting in a day or at most a few days.

Remember, you can still comment during public review.

Krste


No vector TG meeting tomorrow - preparing to start public review

Krste Asanovic
 

There have been no substantial objections raised on the v1.0-rc1 draft, so I will cancel the meeting tomorrow.

There are some minor suggestions and edits (thank you!), and I will incorporate these into the v1.0 version which we’ll freeze for public review, hopefully starting in a day or at most a few days.

Remember, you can still comment during public review.

Krste


Potential Vector Task Group Meeting and v1.0-rc1 review reminder by June 25

Krste Asanovic
 

Unless there are significant issues raised by the group on the v1.0-rc1 spec, the intent is to go into public review on June 25th, so please make sure to give any feedback before then.
There are a few pending edits received already - thank you all for the feedback.

Reminder that there will be no vector TG meeting this Friday, but we have tentatively scheduled a meeting next Friday June 25.
We will only meet on June 25 if there are issues raised that would stall freeze and entering public review.

Remember, it is also possible to give feedback during the public review period.
The main goal before June 25 is to make sure the group is OK with this version being officially frozen and released to the wild for review.

Krste

121 - 140 of 790