| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 01:14 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 01:15 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 02:05 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 02:06 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 02:51 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 02:55 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 03:26 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 04:01 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 07:44 | |
| toshywoshy | markos: yes that should work according to the specs | 07:47 |
|---|---|---|
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 08:38 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 08:52 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 10:05 | |
| markos | toshywoshy, I see that power8 can use 1600Mhz DDR3 as well | 10:17 |
| toshywoshy | Well, any RAM that is compliant with the full JEDEC spec will drop down, to the CPU or memory controller Mhz | 10:18 |
| toshywoshy | the POWER8 cpu and Centaur RAM controller on those machines runs on 1333Mhz, but you can put faster memoery in there, it just won't work at those speeds | 10:18 |
| markos | I'm asking because I found a "POWER8 Memory Buffer" which states the "Operational maximum frequency targets" as DDR3 - 1600Mbps | 10:23 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 10:24 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.199> has joined #libre-soc | 10:24 | |
| markos | and it also seems to support 16GB DIMMs which is great as I found a cheaper 128GB 8x16GB DDR3 12800R listing on ebay | 10:24 |
| markos | https://www.setphaserstostun.org/power8/power8_memory_buffer_um_1.1_pub.pdf the document I mentioned | 10:24 |
| markos | also, do you happen to know what kind of rack rails these systems take? I could not find any such info on either tyan's site or the ebay seller | 10:35 |
| markos | the good thing is that all docs are still available on tyan's site | 10:35 |
| toshywoshy | the buffer document you link to is a general one, in general the POWER8 and POWER9 machines have 2 types of memory buffers, the Centaur buffer, can be DIMM RAM based and the CDIMM RAM ones, in one the buffer is common for all DIMMs and in the other each CDIMM has it's own Centaur buffer | 10:42 |
| toshywoshy | the Tyan one is a general Centaur Buffer, so it will fall back to the lowest speed, mostly being the CPU | 10:43 |
| toshywoshy | in the POWER8 systems there are 3 types of CPU. an SCM, and SCM buffered, and a DCM bufferd, each type had 2 iterations, sometimes referred to as POWER8 and POWER8+ | 10:45 |
| markos | ah right | 10:46 |
| toshywoshy | Tyan only produced systems with the very eary POWER8 CPU with a common Centaur buffer, so the CPU will be the slowest comoponent and the front side bus will drop down to that speed, which if I remember well is the 1333Mhz | 10:48 |
| toshywoshy | As for the rails, I do not remember which rails, but I do rmember that they were fixed rail kits, and quite difficult to take in and out of the rack, I will see if I can find some information on that | 10:51 |
| markos | eg will this ram work? even at lower speed: https://www.ebay.com/itm/256002486251 | 10:54 |
| markos | it's 128gb at a lower price than the other at 64gb | 10:55 |
| toshywoshy | yes, these should work | 11:00 |
| markos | great | 11:01 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.199> has quit IRC | 11:30 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.199> has joined #libre-soc | 11:30 | |
| markos | got 2x 128GB for 68eur, that's a good deal -if they work at all :) | 11:43 |
| markos | sorry, 68eur each | 11:43 |
| *** openpowerbot_ <openpowerbot_!~openpower@94-226-187-44.access.telenet.be> has quit IRC | 11:49 | |
| *** openpowerbot_ <openpowerbot_!~openpower@94-226-187-44.access.telenet.be> has joined #libre-soc | 12:02 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.199> has quit IRC | 12:06 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.199> has joined #libre-soc | 12:07 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.199> has quit IRC | 12:21 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.199> has joined #libre-soc | 12:23 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.199> has quit IRC | 12:37 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 12:38 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 12:51 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 13:47 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 13:47 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 14:34 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.47> has joined #libre-soc | 14:35 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.47> has quit IRC | 15:01 | |
| markos | lkcl, can setvl take a dynamic VL? | 16:36 |
| markos | just saw a particular piece of code that copies only up to certain bytes, but this is runtime known only | 16:37 |
| markos | in particular up to min(64, N) bytes | 16:39 |
| markos | note, I'm not asking for something like fail-first | 16:46 |
| markos | ie on a condition if it finds a null-byte or something siilar | 16:47 |
| markos | but this is necessary if I need to process eg. 64 bytes at a time in an algorithm | 16:47 |
| markos | in order to handle the remaining bytes | 16:47 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 16:50 | |
| ghostmansd[m] | https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1378135-patches-for-baikal-refused-to-be-accepted-into-the-linux-kernel-for-political-reasons | 16:50 |
| ghostmansd[m] | programmerjake, that's yet another example of "overreacting", eh? | 16:51 |
| markos | sigh | 16:54 |
| programmerjake | idk, they may have just done that on their own volition. i haven't researched it beyond reading the phoronix article | 16:56 |
| programmerjake | maybe they knew that company was sanctioned and didn't understand what restrictions that meant were legally required so refused out of caution? | 16:58 |
| programmerjake | it's also totally possible they used that as an excuse and just don't like russia, idk | 16:59 |
| programmerjake | or maybe that someone from their govt. told them they didn't like them accepting patches | 17:00 |
| markos | oh wait, it already can do that (set VL dynamically, that is) from a register! exactly what I want | 17:15 |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 17:47 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 19:11 | |
| lkcl | markos, yes. when RA!=0 then the equation is: VL = RT = MIN(MAXVL, RA) | 19:46 |
| lkcl | you're talking literally and precisely about the *original* Cray-I ISA from which setvl originates | 19:47 |
| lkcl | anything in addition to that (CTR-setting Mode, VFirst Mode) is new | 19:47 |
| lkcl | i believe the Cray Y-MP-1 technical reference manual is available online, it has the complete ISA listing | 19:49 |
| lkcl | you may find these fascinating https://ftp.libre-soc.org/cray-1-pocket-ref/ | 19:51 |
| lkcl | in particular https://ftp.libre-soc.org/cray-1-pocket-ref/FXaLfbWVsAAYa4G.jpeg | 19:52 |
| lkcl | 0020xk - "Transmit register Ak to VL" | 19:52 |
| lkcl | markos, just remember to set MAXVL to the required maximum allocation of elements | 20:05 |
| lkcl | that's what makes the difference between Cray, RVV, NEC SX-Aurora and other Cray-like Variable-length Vector ISAs: MAXVL is the number of *elements* not a *hardware*-architecturally-defined hard-coded constant | 20:06 |
| markos | yup, already found it, checked the pseudocode again :) | 20:44 |
| markos | almost done | 20:45 |
| markos | lkcl, is sv.add/w=32 *x, *x, *j enough if I want to have additions happen in 32-bit chunks of a bunch of registers or do I have to do anything extra? | 22:03 |
| markos | yup | 22:09 |
| markos | never mind | 22:09 |
| lkcl | yep, all packed. | 22:57 |
| lkcl | no zeroing, no gaps | 22:57 |
| lkcl | *including* if VL is an odd number | 22:57 |
| lkcl | so the last element will *not* wipe out the top-half of the (actual, underlying, 64-bit) last GPR | 22:58 |
| lkcl | its contents *remain* intact. because what actually happened in the hardware was: the 4 byte-write-enable lines to that GPR for the *bottom* half are activated, whilst the 4 for the *top* half are NOT | 22:59 |
| markos | almost there | 23:02 |
| markos | so, I have the basic logic in encrypt_bytes all done | 23:02 |
| markos | it produces exactly the same cipher as the C code when *no quarterround* is called in both cases | 23:03 |
| markos | but when I enable the quarterrounds -which I have moved to a macro | 23:03 |
| markos | it fails | 23:03 |
| markos | I think I might be clobbering some register somewhere | 23:03 |
| markos | need to investigate | 23:03 |
| markos | but it's good progress | 23:03 |
| markos | the quarterround snippet is exactly the same as the smaller function and it works there | 23:04 |
| markos | anyway, I'm beat I'll continue tomorrow, I'll let you know :) | 23:06 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
