| lkcl | toshywoshy, this link's non-functional (and linked from wikipedia) https://openpowerfoundation.org/cores-and-more/ | 08:57 |
|---|---|---|
| lkcl | ghostmansd[m], moornin | 13:01 |
| lkcl | the reason for not allowing vec2/3/4 overrides is down to swizzle, which can change the length of the *source* subvector. | 13:01 |
| lkcl | but not the dest subvector | 13:01 |
| lkcl | (or it is the other way round, i forget which) | 13:02 |
| lkcl | https://libre-soc.org/openpower/sv/mv.swizzle/ | 13:02 |
| lkcl | mv.swizzle RT.XYZ RA.W1Y | 13:03 |
| lkcl | the destination is a vec3, but RA is a vec2, because of the "1" | 13:03 |
| lkcl | RT.X=RA.W | 13:03 |
| lkcl | RT.Y=1 | 13:04 |
| lkcl | RT.Z=RA.Y | 13:04 |
| lkcl | if any of that's allowed to be macro-i-fied it's going to get out-of-hand pretty quickly | 13:04 |
| lkcl | including the "meaning" | 13:05 |
| lkcl | copying a 3-long swizzle source to a 2-long destination is not obviously a syntax error, it may be deliberate | 13:06 |
| lkcl | so would not have a syntax error thrown | 13:06 |
| lkcl | putting a foot down and saying "vec2/3/4" is a mode, modes are part of the instruction, instructions are not permitted to be macro'd | 13:07 |
| lkcl | if people *really* want to do it they can use "gcc -E" which works really well to perform much more sophisticated #defines. | 13:07 |
| ghostmansd[m] | Ok fair enough, let's consider each of them as a mode | 13:44 |
| ghostmansd[m] | And, as I understood, key-value modes can all have "value" part defined, right? | 13:45 |
| ghostmansd[m] | Or, well, macro'd. As long as it can be expanded to constant, of course. | 13:47 |
| lkcl | yes. | 13:58 |
| lkcl | there should only be those two: sm= and ew= | 13:58 |
| lkcl | predicate masks are obvious because they select registers. registers should be macro-selectable | 13:59 |
| lkcl | ew=8/16/32/64 is *the* sole exception to the rule of not letting "modes" be changeable | 14:00 |
| lkcl | i can see value in allowing macro redefines changing the maximum number of registers allocated and at the same time adapting the element width | 14:01 |
| ghostmansd | lkcl, https://libre-soc.org/irclog/%23libre-soc.2022-07-08.log.html#t2022-07-08T13:58:42 | 21:05 |
| ghostmansd | Actually there're more. Key-value pairs which I found are: m, dm, sm, ew, sw, ff, pr. | 21:05 |
| ghostmansd | All m/dm/sm rely on the same stuff, though: decoding the predicate. | 21:06 |
| ghostmansd | Same for ew/sw: they decode the width. | 21:06 |
| ghostmansd | ff/pr decode RC1 and branching. | 21:08 |
| ghostmansd | So, yeah, not much options. | 21:08 |
| lkcl | yep. puzzlingly/amazingly | 21:43 |
| lkcl | "m=XX" is short-hand for "dm=sm=XX" | 21:43 |
| lkcl | yes, ff/pr are modes | 21:44 |
| Manili | Hi all! I hope you are doing well all over the world! I'm pretty much new to the libre-soc project and after talking to lkcl he told me to join here and ask my questions. First of all I'm really curious to know the actual status of the GPU development both from SW and HW sides? I have read the website before, but I'm looking for current updates. | 22:36 |
| Manili | Thanks a lot guys. | 22:36 |
| octavius | Hi Manili, nice to meet you :) | 22:38 |
| octavius | The libre-soc core is able to operate in place of a microwatt cpu atm (recently Tim was able to run a basic server), however I don't know the details of the GPU instruction progress | 22:38 |
| lkcl | Manili, welcome | 22:40 |
| octavius | https://bugs.libre-soc.org/show_bug.cgi?id=855 | 22:40 |
| programmerjake | Kazan, a Vulkan driver is somewhat stalled at the moment (I've been busy working on hardware stuff) | 22:41 |
| lkcl | the "GPU" aspect is hard to pin down because we're designing a hybrid CPU-VPU-GPU | 22:41 |
| lkcl | therefore the very first thing that has to be done is: design a Scalable Vector Processor ISA | 22:41 |
| lkcl | oh and along the way make sure it has the capability and capacity that is normally covered *by* GPUs. | 22:42 |
| programmerjake | We still haven't started on some GPU-specific instructions such as triangle rasterization acceleration or texture instructions, most of the general compute stuff needed for GPUs is coming along nicely | 22:42 |
| programmerjake | we're just starting on getting compiler support, so far we have mostly complete (so-far) binutils support, but gcc and llvm haven't gotten very far | 22:43 |
| Manili | Hi octavius, lkcl and programmerjake. You are all SUPER FAST guys! I really didn't expect that:D So looks like I shouldn't start my journey from GPU part of the wiki. Any suggestions? | 22:45 |
| lkcl | the Simple-V spec | 22:46 |
| lkcl | 1 sec | 22:47 |
| programmerjake | well, if you don't mind getting into the deep end, you could start with SimpleV | 22:47 |
| programmerjake | https://libre-soc.org/openpower/sv/ | 22:47 |
| programmerjake | https://libre-soc.org/openpower/sv/overview/ | 22:48 |
| * lkcl must put this on the page https://ftp.libre-soc.org/simple_v_spec.pdf | 22:49 | |
| Manili | OMG! That's a lot to read but I'll read it as a reference book so just try to understand the big pic. | 22:51 |
| Manili | Agree? | 22:51 |
| lkcl | the total page count for Simple-V is around 160. | 22:52 |
| lkcl | (bear in mind that the Power ISA v3.1 specification is 1,400) | 22:52 |
| Manili | Oh, got it. | 22:53 |
| lkcl | you may find the insights here useful https://libre-soc.org/openpower/sv/vector_isa_comparison/ | 22:53 |
| lkcl | if you are familiar with any [mis-named] "Vector" ISAs which happen to have the word "Vector" in their name, such as AVX-512 | 22:53 |
| lkcl | or the PackedSIMD VSX | 22:54 |
| lkcl | 200+ pages of the PDF are actually *Scalar* instructions and supporting tables and pseudocode, | 22:54 |
| lkcl | because SV does not add - or contain - Vector instructions in any way, shape or form | 22:55 |
| lkcl | it contains the *abstracted concept* of Vectorisation, aka "looping". | 22:55 |
| lkcl | you'll see in the overview. | 22:55 |
| Manili | OK, so let's do it! | 22:56 |
| Manili | Is that the reason behind not choosing the RISC-V (i.e. its vector instruction set was not ready yet)? | 22:56 |
| lkcl | there are multiple reasons for not choosing RISC-V | 22:57 |
| lkcl | from a technical perspective, RISC-V is slowly being discovered to be inadequate. | 22:58 |
| lkcl | https://news.ycombinator.com/item?id=24459314 | 22:58 |
| lkcl | https://groups.google.com/g/comp.arch/c/PCyKnVva39A/m/42-dBepHAgAJ | 22:59 |
| Manili | Thanks a lot guys. That was a lot of info. Please gimme some time to read all these invaluable docs and I'll brb with a lot of questions. | 23:02 |
| Manili | :D | 23:02 |
| lkcl | Manili, :) | 23:02 |
| lkcl | what's your interest, here? what motivates you, if you don't mind me asking? | 23:02 |
| lkcl | are you in academic research? or a Libre/Open developer? | 23:03 |
| Manili | Sure! I love all different aspects of the project. So I'm currently just searching around to find what really fits me. About your second question, I'm learning VLSI and chip design so I found this project really interesting to learn new stuff. | 23:07 |
| Manili | I'm looking to help the community in the future if I can. | 23:08 |
| lkcl | nice. well if it helps at all we have NLnet funding, and there's a huge variety of things at different levels | 23:47 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!