How to propose a new SIMT (GPU) extension ISA?

[Hyesoon Kim]

Hello, 

We have been very actively developing an open source RISC-V GPU  (https://vortex.cc.gatech.edu/) S/W and H/W which uses new ISAs that we proposed. 

wspan, tmc, split/join, bar, tex (and a few 3D graphics ISAs). 

We would like to propose an ISA extension so that it can be more official. 

Can someone help us how to proceed the proposal? 

Thanks,

Hyesoon 

[Mehmet Oguz Derin]

It might help to post this in Graphics and ML https://lists.riscv.org/g/sig-graphics SIG, which has GPGPU as a natural focus. - Oguz

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/73705bc4-28a8-46c3-9cd9-04ca054bb087n%40groups.riscv.org.

[Jim Wilson]

The RISC-V International Wiki

     https://wiki.riscv.org/

has a RISC-V Developer Getting Started Guide which has a section on specifications which explains how they are developed.  This has pointers to other documents that go into more detail about the process.

To start, you need to be a member ideally, or convince a member to act on your behalf.  Then you start attending meetings for relevant groups and make proposals and try to convince people to start a new group to be in charge of the extension  you are proposing.  The new group will need a chair and co-chair and regular meetings.  There may be counterproposals.  Or other people wanting to make changes to your extension.  If you can get agreement on an extension, then you need to convince the higher up gatekeepers that this needs to be added to the ISA, at which point there will be more changes required.  There is a list of requirements to meet such as having software support and a formal specification in SAIL.  If you aren't a member, there will be copyright, patent, and other IP issues to deal with.  Then eventually a public review period and a vote for ratification.  The whole process will likely take a few years unless it is something small, which this is probably not.  There is a Graphics and ML SIG where you might want to start to gauge interest.  You have to be a member to join that group.  And perhaps also the unpriv ISA group since this is an ISA extension.  This also requires membership.

isa-dev is an open mailing list.  Nothing official can happen here, as there is no IP protection here.

Jim

[Tommy Murphy]

> isa-dev is an open mailing list.  Nothing official can happen here, as there is no IP protection here.

Hi Jim

Can you (or others) explain this further or point to something that does?

I thought that RISC-V was an open standard?

Why is IP protection an issue in the context of a new extension proposal?

Thanks

Tommy

[Greg Favor]

On Tue, May 17, 2022 at 6:45 PM Tommy Murphy <tommy_...@hotmail.com> wrote:

> isa-dev is an open mailing list.  Nothing official can happen here, as there is no IP protection here.

Can you (or others) explain this further or point to something that does?

I thought that RISC-V was an open standard?

Yes, RVI standards are open standards.  But to truly be open standards, they also need to not be encumbered with other people's IP.

So when members contribute to the development of a RISC-V standard, their RVI membership agreement requires that they must not introduce encumbered IP into specifications and that rights to any IP developed as part of a RISC-V standard belong to RVI.

Greg

[Tommy Murphy]

Thanks Greg.

I misunderstood the reference to IP protection as referring to RISC-V International being the entity that might be claiming IP rights/protection.

[BGB]

I am partly confused if the idea here is:
  Running RISC-V on a GPU, probably with its own ISA for rendering
stuff (for GPGPU tasks);
  Or, using RISC-V as the basis for a GPU ISA.

IMHO, the former here makes more sense than the latter.

I wouldn't consider RISC-V to be the ideal starting point in the design
of an ISA intended to run a GPU, and if one did it would likely need to
beaten beyond recognition to have much hope of performance at 3D
rendering tasks.


Say, one needs things like, say:
  128-bit SIMD vectors;
    At least on the front-end vertex transform;
    Rasterization could work OK with mostly 64b vectors (packed int16
or half-float);
    ...
  Instructions for things like:
    Performing texture fetch (Eg: special addressing mode for 2D
texture vectors);
    Compressed texture decoding;
    Bilinear interpolation;
    Packing and unpacking RGBA;
    ...

Could work with 64-bit registers, but a case could be made for going
with 128-bit registers as the baseline.
  Things like addresses or 64-bit types merely ignoring the high part
of the register, or holding metadata.
    Say, for a texture, the high bits could encode things like the
texture size and format.
    ...


Can note that I have implemented "OpenGL style" 3D rasterization in my
case (via software rasterizer in my own ISA), so have a general idea
with what would be needed (but, will admit that what I have still falls
well short of getting playable framerates in GLQuake on a CPU core
running at 50MHz; still would apparently kinda need ~ 100 or 150 MHz for
GLQuake to be "playable").

Albeit, this is with a single thread running both the Quake engine and
GL rasterizer; and my core has reached such a size that I can't go
dual-core on the FPGA that I am currently using (though, even if I
could, it wouldn't really increase the usable DRAM bandwidth, which is a
bit of a bottleneck in this case). Though, "bigger and more expensive
FPGA" has some obvious drawbacks as well.

In this case, slowness isn't entirely due to the rasterization, as the
GLQuake engine spends considerable time in "R_RecursiveWorldNode" and
RecursiveLightPoint and other related functions (can disable GL's
drawing entirely, with calls like glBegin/glEnd/glVertex3fv/...
effectively turned into NOPs, and it is still pretty slow).


In any cases, yeah, if there is any "proprietary" stuff, probably don't
want to pollute RISC-V with it.

Like, say, usually one doesn't want to add too much that doesn't have
prior art that is older than 20 years or so.

In my own unrelated ISA design, I think I am OK here, as there isn't all
that much that I haven't found prior art for in some form...


Then again, I can note that the S3TC patent existed for a while, despite
the same basic design having been used in plenty of stuff predating
S3TC, and it having not really done anything "new" if compared with
previous color-cell variants.

> --
> You received this message because you are subscribed to the Google
> Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to isa-dev+u...@groups.riscv.org.
> To view this discussion on the web visit

> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/LO2P265MB4776B35C7F4EA0F7C891D8F2F9D09%40LO2P265MB4776.GBRP265.PROD.OUTLOOK.COM
> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/LO2P265MB4776B35C7F4EA0F7C891D8F2F9D09%40LO2P265MB4776.GBRP265.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.

[Abel Bernabeu]

Am happy to continue this conversation on: sig-gr...@riscv.org

:-)

We need more people with an interest on graphics to help review and drive proposals there.