| Veera | Hi | 03:13 |
|---|---|---|
| programmerjake | hi | 03:34 |
| Veera | programmerjake: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/test/alu/alu_cases.py | 03:43 |
| Veera | programmerjake: Luke told me to open a bug report: adapt ALU test cases to include expected results | 03:44 |
| Veera | in which to open | 03:45 |
| programmerjake | ok... | 03:45 |
| Veera | Libre-SOC's first SoC or Libre-SOC's second ASIC | 03:45 |
| Veera | And Under which component this bug to be opened in Bugzilla | 03:45 |
| programmerjake | probably first soc, and under source code, if that's wrong luke can reassign it | 03:46 |
| Veera | ok | 03:46 |
| Veera | thanks | 03:46 |
| programmerjake | which bugzilla category you pick may not matter all that much | 03:47 |
| Veera | programmerjake: what is the status of kazan work in concern with Libre-SOC | 03:47 |
| Veera | oh | 03:48 |
| programmerjake | kazan is currently stalled because i'm working on other stuff | 03:48 |
| Veera | oh | 03:49 |
| Veera | need any help with installation, setup of mesa and related softwares? | 03:49 |
| programmerjake | i'm at a point where most of the design is in my head and it's currently kinda a one person job till I get the basic architecture written | 03:50 |
| programmerjake | nah, I've got building mesa mostly all figured out, thx anyway | 03:50 |
| Veera | ok | 03:50 |
| Veera | have you put those instructions some where on wiki? | 03:52 |
| programmerjake | for building mesa? no, i don't need to build it to work on kazan, and I figured out how to build it years before working on libre-soc, so, no, i didn't put mesa build instructions on the wiki | 03:53 |
| Veera | oh | 03:54 |
| Veera | ok | 03:54 |
| programmerjake | kazan is a totally independent vulkan driver, it doesn't use mesa | 03:54 |
| programmerjake | the libre-soc mesa driver is separate | 03:55 |
| Veera | for display what it uses? | 03:55 |
| programmerjake | the standard x11, wayland, and linux kernel drm interfaces | 03:56 |
| programmerjake | though that is a ways off, i'm going to implement off-screen rendering first | 03:57 |
| *** henriok_ is now known as henriok | 06:54 | |
| lkcl | Veera[m], for the alu_test_cases.py it is so low-level you do not need any high-level software such as mesa drivers. | 09:33 |
| lkcl | the alu test cases are literally running one to three instructions | 09:33 |
| lkcl | high-level software such as mesa is running literally millions to billions of instructions | 09:34 |
| programmerjake | lkcl: afaict he was volunteering to figure out how to build mesa for use with kazan's development, not with alu_test_cases.py | 09:36 |
| programmerjake | lkcl i'll respond to your other SimdSignal messages in the morning | 11:25 |
| lkcl | ahh ok | 12:11 |
| lkcl | yes no problem | 12:11 |
| lkcl | programmerjake, appreciate you're probably asleep by now :) | 13:47 |
| lkcl | some notes / insights: it's rather unfortunate that what i have put together for SimdSignal is an absolutely massive inter-connected chain of approximately 8 distinct moving inter-related parts | 13:49 |
| lkcl | where until all of those parts are completed there is nothing that can be provided which actually demonstrates that it will be successful. | 13:49 |
| lkcl | the big part - the king-pin / corner-stone - is an over-ride of ast.Switch (which now redirects to Value.__Switch__ which can be over-ridden) | 13:50 |
| lkcl | which, if you look closely at dsl.Module, *everything* thunks down through that one function. m.If/Elif, m.FSM, m.Switch/Case, they all redirect down through ast.Switch (now Value.__Switch__ which we can now override with SimdSignal.__Switch__) | 13:52 |
| lkcl | that one thing was the subject of literally weeks of study to verify and ensure that it would work. | 13:52 |
| lkcl | there was one scary moment a couple weeks ago where i realised that the original design for SimdSignal.__Switch__ was not going to work, but i quickly came up with a solution | 13:53 |
| lkcl | now, when you said "the whole thing hangs on type substitution in python" you were absolutely correct | 13:53 |
| lkcl | but i detected / suspect that you were saying this not in a positive way but in a slightly disparaging one. | 13:54 |
| lkcl | the whole point *is* to use the Liskov Substitution Principle which python is famously well-known for! | 13:54 |
| lkcl | now, it may make people _nervous_ to make such a massive substitution (Value has over 30 functions, each of which has to be implemented in full, providing full dynamic parallelism on absolutely every single one of those 30 AST Type 1 operators) | 13:56 |
| lkcl | but just because people are nervous and/or do not understand it and/or in the nmigen maintainers case wish to dictate and declare that all and any possibility *of* doing such large LSP is "prohibited because we said so" | 13:58 |
| lkcl | these are not good enough justifications for trying (and succeeding) | 13:58 |
| lkcl | particularly when the alternatives are absolutely awful and have consequences that range from "seriously problematic" to "absolutely catastrophic" for both nmigen and libre-soc, long-term | 13:59 |
| lkcl | dsl.py is a *thousand five hundred* lines of extremely complex code. | 13:59 |
| lkcl | absolutely none of which, through deployment of Liskov Substitution Principle at the ast.* level, either needs replacing or significantly modifying. | 14:00 |
| lkcl | even to attempt to do so is itself a massive project | 14:01 |
| lkcl | (for which we do not have time) | 14:01 |
| lkcl | i documented the other reasons - and there are several - at the end of this document https://libre-soc.org/3d_gpu/architecture/dynamic_simd/ | 14:01 |
| lkcl | substitution in python *is* its strength: it's precisely why i picked it. | 14:04 |
| lkcl | it's a beautiful and extremely powerful feature / capability | 14:04 |
| lkcl | that i have successfully exploited to the absolute max. | 14:05 |
| lkcl | dropping in alternative objects that have the same API without having to rewrite somebody else's python code should not be taken as a "weakness" or "something to be avoided at all costs", it should be celebrated! | 14:06 |
| lkcl | so, i apologise: we need to complete SimdSignal.__Switch__ before i can demonstrate and show that this is going to work | 14:07 |
| lkcl | but there are a ton of smaller pieces that are needed before that can even be done | 14:08 |
| lkcl | so please: trust me and help me to get this completed | 14:08 |
| lkcl | kylel, https://bugs.libre-soc.org/show_bug.cgi?id=717 testapi looks great i did a whitespace cleanup | 15:26 |
| kylel | Yeah thanks, markdown sometimes beats me down. :-) | 15:27 |
| lkcl | haha | 15:27 |
| lkcl | This API helps to define a standard way to collect and compare the results from different implementations by abstracting away a certain level of complexity. | 15:28 |
| lkcl | hmmm... | 15:28 |
| lkcl | implementations of what? | 15:28 |
| lkcl | suggest not including the word "complexity" | 15:28 |
| lkcl | collect and compare the results of different Power ISA systems, in order to allow different teams to cross-verify their implementations against each other | 15:29 |
| lkcl | Examples include testing qemu's execution against the execution of the same program on an IBM POWER9 system | 15:30 |
| lkcl | something like that | 15:30 |
| kylel | good point | 15:33 |
| lkcl | leave it with you? | 15:37 |
| kylel | oh sure, are you done with commits? | 15:37 |
| lkcl | the wiki uses git so there's never a chance of conflict unless you happen to be editing the exact same line | 15:41 |
| lkcl | even then, it's resolvable | 15:41 |
| lkcl | but yes :) | 15:41 |
| kylel | being that I'm married, I try to avoid conflicts. :) | 15:47 |
| Veera[m] | Hi | 16:32 |
| Veera[m] | <lkcl> "Veera, for the alu_test_cases.py..." <- No it isn't related. It was a separate chat! | 16:35 |
| lkcl | Veera[m], ok :) | 17:23 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!