<Sarayan>
wq: I have a feeling we both need a waveform visualization interface that is not a GUI over pure pain?
<whitequark>
well, sure
<Sarayan>
ok, I'll probably start something and see how it goes
<Sarayan>
because gtkwave is not going to get better
<cr1901_modern>
catch the qtwave?
<Sarayan>
something like that
<cr1901_modern>
The logo can be Max Headroom holding an aluminum can with the qtwave logo on it
jeanthom has quit [Quit: Leaving]
jeanthom has joined #nmigen
<Sarayan>
Need more of a feminine touch in honor of wq :-)
<cr1901_modern>
Also probably a reference to something from this century would help
<Sarayan>
no covid of floyd though, something positive, if we can find some
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<whitequark>
heh
<whitequark>
Sarayan: my approach to this would be to render via gl and do heavy mipmapping in software
<whitequark>
might actually look at how gtkwave implements this, i think the algorithms in it are sound
smkz has quit [Ping timeout: 256 seconds]
FFY00 has quit [*.net *.split]
FFY00 has joined #nmigen
smkz has joined #nmigen
<whitequark>
awygle: so i had this idea
<whitequark>
what if we had `cxxrtl_step_fast` that only updates the simulation state, and `cxxrtl_step` that updates simulation state and every derived signal?
<Lofty>
whitequark: What's a "derived signal" here?
<whitequark>
any signal that is not a part of feedback
<whitequark>
think, any signals not driven by FFs
<whitequark>
(but that's a simplified view)
<Sarayan>
wq: Lately I tend to be more Vulkan than GL, but otherwise I agree with you
<whitequark>
Vulkan is probably ok too
<Sarayan>
yeah
<whitequark>
I would pick GL conservatively to make the tool more useful, but I wouldn't argue against Vulkan either
<whitequark>
*useful to more people
<cr1901_modern>
My primary laptop can't run Vulkan
<Sarayan>
well, to make something that works and is cleanly designed first
<cr1901_modern>
Sandy Bridge
<Sarayan>
You'll do a dx12 version or whatev'
<Sarayan>
SB has vulkan support in linux too :-P
<cr1901_modern>
Oh, I wonder if it has Windoze support then
<cr1901_modern>
I was certainly under the impression that Ivy Bridge was the hard cutoff because EDONTCARE
<Sarayan>
probably not
<Sarayan>
not two years ago at least
<hell__>
doesn't vulkan require hardware support?
<Sarayan>
well, sane gl does too
<hell__>
ah yes
<Lofty>
I'm fairly sure the old TeraScale GPUs needed F64 emulation
<Lofty>
So, there are bits you're allowed to emulate to some extent
<Sarayan>
you're allowed to emulate everything in gl
futarisIRCcloud has joined #nmigen
<hell__>
you also need to emulate patience then, because emulating things is slower
<hell__>
or use natural reserves if they exist, ofc
<Lofty>
Sure, but to claim compliance with a GL spec you need to implement everything and have it run correctly
<Lofty>
It doesn't need to run *quickly*
<hell__>
yup
<hell__>
I forgot that I once tried to run relatively recent games on a Nvidia GeForce MX400 with 64 MiB of RAM
<hell__>
I think I ended up using some software rendering library, and the space heater pretending to be a processor (the fastest Pentium 4 for Socket 478) did what it did
<hell__>
one would need to count frames per minute :D
<Sarayan>
spf instead of fps
* hell__
first thought of solar protection factor
lkcl_ has joined #nmigen
lkcl has quit [Ping timeout: 260 seconds]
hitomi2500 has quit [Quit: Nettalk6 - www.ntalk.de]
<awygle>
gtkwave is one of those "holding back progress by being terrible but just good enough that no one has replaced it" things
<awygle>
also hi
<Sarayan>
awygle: very much so
<Sarayan>
wq: there are two things there, only save memory (ff), and only save from time to time (and the blackbox/inputs) so that you can regenerate fast
<whitequark>
Sarayan: anyway, to say it explicitly: i have a feature wish that your viewer should be able to understand "keyframes"
<whitequark>
yes
<whitequark>
cxxrtl can already do it.
<whitequark>
not even "can be easily modified", you can just use existing API
<Sarayan>
does cxxrtl have a "pack all state to save into a contiguous block of memory so that saving is an efficient linear memcpy" ?
<Sarayan>
I've finished a bunch of work things the last two days, I think I may have some "free" time for the wave viewer
<Sarayan>
we'd need a different format than vcd though I guess?
<whitequark>
it doesn't, since I'm more concerned with having the C++ compilers do their thing with class members than having linear memcpy
<whitequark>
it doesn't really matter, as long as all of your state fits into cache, and you aren't checkpointing too often, the cost of gathering that data is minimal
<Sarayan>
yeah, if you don't checkpoint after every cycle it indeed doesn't matter
<whitequark>
the VCD writer actually *does* have such a state in a single vector
<whitequark>
but it's just an implementation detail
<whitequark>
for now at least
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<awygle>
FST is actually quite a nice waveform format, and it's separable from gtkwave
<Sarayan>
is there anything that generates it?
<daveshah>
Verilator can generate it
<awygle>
Icarus too
<awygle>
And GHDL iirc
<Sarayan>
so only cxxrtl missing ;-)
<Sarayan>
is it the damn complex one that does compression and stuff?
chipmuenk has joined #nmigen
<awygle>
FST is probably the most complex one yes
<awygle>
i'd recommend you rip the code out of gtkwave, at least to start
chipmuenk has quit [Quit: chipmuenk]
<Sarayan>
Hard no
<Sarayan>
I've looked at that code, and no
<Sarayan>
Just no
<Sarayan>
There's code reuse, and there's spawn of hell reuse
<Sarayan>
So, just no
<awygle>
lol
<awygle>
did you look at the FST code specifically?
<awygle>
idk how badly implemented it is but the API is relatively clean and the code loosely coupled to the rest of hte codebase