| klys | just taking a glance at Libre-SOC, it's missing a reference to Kazan. | 06:31 |
|---|---|---|
| klys | so I think it should probably explain that it uses Kazan as the GPU and credit Jake | 06:32 |
| klys | instead of just mentioning "graphics computing" | 06:34 |
| klys | I mean as an instruction set, not as "the GPU" as I had said, of course. | 06:35 |
| lkcl | klys: it's not missing, it's simply buried under the sheer quantity of working pages that get created as a direct result of development | 06:43 |
| lkcl | if you encounter some specific locations that you think it can be mentioned, please do directly edit the wiki yourelf. | 06:43 |
| lkcl | bear in mind: Kazan is *not* a GPU, or an ISA. it is simply a Vulkan driver. there is a second Vulkan driver, a MESA 3D one being developed by Vivek Pandya | 06:45 |
| klys | whoa you're telling me kazan isn't a set of instructions that can be used as a gpu? | 06:46 |
| lkcl | if you can please edit whatever-pages-you-feel-should-say-whatever to include *both* 3D drivers | 06:46 |
| lkcl | that's correct: it is not. | 06:47 |
| klys | why? | 06:47 |
| klys | it used to be, didn't it? | 06:47 |
| lkcl | Kazan is a piece of *software* | 06:47 |
| lkcl | no, Kazan was never a *hardware* driver or a *hardware* product or project | 06:47 |
| lkcl | it is, has been, and always will be, a *software* driver that *USES* hardware instructions | 06:47 |
| lkcl | it is, has been, and always will be, a *Vulkan* compliant *software* driver | 06:48 |
| klys | reading this: https://www.phoronix.com/scan.php?page=news_item&px=Libre-GPU-RISC-V-Vulkan | 06:48 |
| lkcl | that happens to use the Libre-SOC OpenPOWER instructions | 06:48 |
| lkcl | read this sentence: | 06:49 |
| lkcl | "Along similar lines has been Vulkan-CPU and now known as Kazan as a software/CPU-based Vulkan implementation." | 06:49 |
| lkcl | Kazan is a **SOFTWARE** Vulkan driver | 06:49 |
| klys | Is there a libre-gpu project? | 06:50 |
| lkcl | again, to repeat: it *USES* the opcodes provided by *LIBRESOC* hardware | 06:50 |
| lkcl | this *is* a Libre GPU project | 06:50 |
| klys | no wait | 06:50 |
| klys | the set of instructions that may be used as a GPU is rather simplistic, I get | 06:51 |
| klys | someone might be trying to implement them in riscv | 06:51 |
| klys | is that right? | 06:51 |
| lkcl | good luck to them if they do. | 06:52 |
| klys | if so, it wouldn't be Kazan | 06:52 |
| klys | do you know? | 06:52 |
| lkcl | Kazan is a piece of software. | 06:52 |
| lkcl | you still have in your head the mistaken impression that Kazan is a piece of hardware | 06:53 |
| klys | well I want to hear about a hardware project | 06:53 |
| lkcl | then that is Libre-SOC | 06:53 |
| lkcl | the Libre-SOC core implements hardware opcodes and Vectorisation | 06:54 |
| lkcl | including transcendentals (sin, cos, atan2), bitmanip, and more | 06:55 |
| lkcl | also we have to add Texturisation and pixel format opcodes and a Texture Cache. | 06:55 |
| klys | okay what do you know about rv64x | 06:56 |
| lkcl | as an aside: Kazan, a *software* driver, will happen to *use* all of those opcodes | 06:56 |
| lkcl | it was an initiative by Atif Zazar, over two years ago, that the RISC-V Foundation and Si-Five f*****d over. | 06:56 |
| lkcl | cost him a five figure sum. he was absolutely furious. | 06:56 |
| klys | was it ever standardized? | 06:57 |
| lkcl | a journalist a few months back re-hashed an article published two years ago, putting it back into the news | 06:57 |
| lkcl | no, because the RISC-V Foundation favoured a competing product that was based in the USA and sponged off of EU funding | 06:58 |
| klys | you mean the beaglev | 06:58 |
| klys | ? | 06:58 |
| lkcl | no, it was a proprietary company that specialises in low-power 3D | 06:58 |
| klys | well okay | 06:59 |
| lkcl | they used LLVM and kept all driver modifications entirely secret | 06:59 |
| lkcl | nobody will ever see the code, or the RISC-V custom ISA modifications that that company made. | 06:59 |
| klys | https://salsa.debian.org/Kazan-team/kazan/-/issues/8 | 07:07 |
| klys | if this information is inaccurate, please update | 07:08 |
| lkcl | it's not inaccurate at all. | 07:08 |
| klys | thanls | 07:08 |
| klys | thanks | 07:08 |
| lkcl | Kazan - using the Libre-SOC opcodes - will write to a framebuffer | 07:09 |
| lkcl | the way that a SoC works is that there is a piece of hardware (which has nothing to do with the processor), which scan-reads that same framebuffer and shoves it out to a display | 07:09 |
| * lkcl going back to sleep, it's 7am :) | 07:10 | |
| klys | yeah and the framebuffer is mmap()'d into address space | 07:10 |
| lkcl | by the software driver, either Kazan or the MESA 3D one being written by Vivek, yes. | 07:11 |
| klys | okay | 07:11 |
| klys | I guess in traditional framebuffer implementations it's slow to read the framebuffer so they use double buffering | 07:12 |
| lkcl | unlike a "standard" GPU architecture, if Kazan software driver or the MESA 3D driver being written by Vivek need to e.g. do a SIN or COSINE operation, | 07:12 |
| lkcl | they use an *actual instruction* | 07:12 |
| klys | yeah | 07:12 |
| lkcl | they do not... deep breath | 07:13 |
| lkcl | prepare a queue | 07:13 |
| lkcl | put some stuff into memory | 07:13 |
| lkcl | copy it to shared memory | 07:13 |
| lkcl | communicate with the kernel to tell the kernel it should tell the GPU to read it | 07:13 |
| lkcl | have the GPU unpack the command | 07:13 |
| lkcl | have the GPU execute the SIN/COSINE operation ... | 07:14 |
| lkcl | you get the idea | 07:14 |
| lkcl | insane | 07:14 |
| klys | yeah because it's part of the cpu to begin with | 07:14 |
| lkcl | exactly | 07:14 |
| lkcl | double buffering is there to stop "tearing" | 07:14 |
| lkcl | that scan-line reading i mentioned above? | 07:14 |
| lkcl | if you get it wrong and happen to write at the time that the hardware is reading | 07:15 |
| lkcl | you end up with shite on the display. | 07:15 |
| lkcl | solution: | 07:15 |
| lkcl | two buffers. | 07:15 |
| lkcl | one you are writing to | 07:15 |
| lkcl | whilst the hardware is reading from the other | 07:15 |
| klys | that's part of the retrace handling used in vga | 07:15 |
| lkcl | it's been a known problem for 40-50 years. | 07:16 |
| lkcl | it doesn't actually have anything to do with GPUs per se | 07:16 |
| klys | I've got some work at getting graphics on the linux tty here: https://github.com/mdasoh/drm-kms/ | 07:16 |
| lkcl | the Amiga had a special... something. where it could detect where the hardware was up to | 07:16 |
| klys | so yeah there's that and vsync handling | 07:17 |
| lkcl | and it could wait until the hardware had outputted the scan line it was up to before overwriting | 07:17 |
| lkcl | yeah | 07:17 |
| klys | the atomic modesetting is only avaliable with newer gpu hardware | 07:17 |
| klys | I've been testing it on an older radeon and it requires those things | 07:18 |
| klys | well I mean the amiga, yeah, it had highly nonstandard stuff like the vidiot | 07:19 |
| * lkcl apologies klys i need to sleep / rest. 7am here. | 07:19 | |
| klys | okay sweet dreams lkcl | 07:19 |
| lkcl | i've been registering on a couple of sites, it would be good if everyone could do so as well. | 16:06 |
| lkcl | https://www.librecores.org/libre-soc | 16:06 |
| lkcl | interestingly that's a libre/open project (librecores source code is itself libre and self-hosted) | 16:07 |
| lkcl | i've added ieee754fpu, nmutil, and openpower-isa | 16:16 |
| lkcl | cesar[m]1, i'm just filling in some TODO comments into the EXECUTE_WAIT FSM state, for LD/ST exceptions. can you take a look? | 17:14 |
| cesar[m]1 | Sure. | 17:15 |
| lkcl | magic. will just commit in a moment | 17:15 |
| lkcl | basically, the exception needs to be noted, copied into pdecode2.ldst_exc (sync +=) | 17:19 |
| lkcl | then the instruction simply *re-executed* | 17:20 |
| lkcl | PowerDecoder2 will pick up that the ldst_exc has been activated | 17:22 |
| lkcl | and will completely rewrite the info in PowerDecoder2, with an OP_TRAP, a new MSR and a new PC. | 17:22 |
| lkcl | it _should_ be quite straightforward | 17:33 |
| lkcl | cesar[m]1, sorry, i'm adding some infrastructure for fast3 (SVSRR0) | 18:10 |
| lkcl | this is the other website https://opencollective.com/libre-soc | 19:02 |
| *** henriok <henriok!~henrik@81-229-9-109-no92.tbcn.telia.com> has left #libre-soc | 21:00 | |
| lkcl | random meeting 20mins | 22:40 |
| lkcl | cesar[m]1 lxo jn__ programmerjake ^ | 22:40 |
| lxo | calling in... | 23:05 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!