ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow
ExeciN has joined #glasgow
<electronic_eel>
whitequark: I thought I'd try your yamaha web gateway, but unfortunately I always get a "502 Bad Gateway" back. Is that a known problem?
<whitequark>
electronic_eel: it runs on my laptop.
<whitequark>
so when i want to do something else with it, i shut it down
<electronic_eel>
ah, ok.
<electronic_eel>
no worries, will try it later. Just thought it maybe was a problem you didn't know about
<whitequark>
give me a sec
<whitequark>
electronic_eel: try now
<electronic_eel>
yeah, can connect now
<electronic_eel>
hehe, nice thing to play with
<electronic_eel>
"I hate Web. I hate audio. I especially hate web audio." is a bit in a conflict with all the effort done in the script...
<electronic_eel>
no, not done. I meant put into
<electronic_eel>
I really don't want to make you to put more work into something ugly and cursed like web audio
<electronic_eel>
but there seems to be a bug when activating the loop flag. It doesn't loop back to 0, but jump to somewhere in the track
<electronic_eel>
I can live without this being fixed, it is just second nature to me to notice and report bugs...
<electronic_eel>
ah, the vgm format has a loop command. So either the loop target in the files I was testing is set incorrectly or there is indeed a bug in the player in this regard
<whitequark>
it jumps somewhere in the track. that's how it's supposed to work
<whitequark>
it doesn't loop *exactly* because of some minor numeric error, but more importantly, because vgm loops via *commands*, not via *gluing pcm together*
<electronic_eel>
hmm, but shouldn't the jump be to some position that fits the music?
<whitequark>
yes
<whitequark>
it is
<electronic_eel>
when you listen to the track I posted above, the loop sounds just like it is to a random position
<whitequark>
not my problem
<whitequark>
i could remove the loop checkbox entirely.
<electronic_eel>
but you are right, there are other songs where the loop sounds nearly correct
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±3] https://git.io/Jen9j
<electronic_eel>
don't worry, I'm just drawn like a fly to light to things that look like bugs
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark bde917e - applet.audio.yamaha_opx: allow providing a link to VGM/VGZ as well.
<whitequark>
ah alright
<whitequark>
in theory looping could be improved by looping once via the command stream
<whitequark>
and gluing *that*
<electronic_eel>
ah, so by letting the actual synth do the loop once
<electronic_eel>
in a game the looping is quite important, don't know how important it is for your web gateway
<whitequark>
well i'm not really sure why i made it
<electronic_eel>
maybe because you could?
<whitequark>
i guess
<esden>
whitequark: that page is so much fun! :D Took me a few tries to find the correct VGM rip file so it did not contain some other random chip support. But it is pretty awesome. :D
<esden>
did you shut it down again?
<whitequark>
esden: some network issues, one moment
<electronic_eel>
collecting old ICs is one thing, making them run again and giving others access is several levels up
<whitequark>
esden: try again
<esden>
you might be slammed a bit now, I sent the link to a friend too :D
<esden>
it is back! :D
<esden>
nice!
<esden>
ohh I guess I glitched it too hard ;)
<esden>
electronic_eel: yes totally!
<whitequark>
esden: there's a concurrency bug somewhere in the OUT URB cancellation code
<esden>
for whitequark sake I would wish the web tech stuff was not so horrible
<whitequark>
anyway i restarted it
<esden>
thanks :D sorry
<esden>
remote hard reset might be useful?
<esden>
I know it is WIP :D
<whitequark>
esden: the thing is that it already does hard reset
<whitequark>
the problem is with the USB code
<esden>
ahh ok
<whitequark>
there is some very complex scheduling involved to make it performant
<whitequark>
that falls apart for reasons i don't entirely understand right now
<electronic_eel>
scheduling inside gateware, in the fx2 or on the pc side?
<whitequark>
pc side
<whitequark>
it crashes with ValueError: Set of coroutines/Futures is empty.
<whitequark>
File "/home/whitequark/Projects/Glasgow/software/glasgow/support/task_queue.py", line 62, in wait_one
<electronic_eel>
1st question: did you try turning it on and off again? 2nd question: did you try a new gpu?
<mwk>
uhh, lots of times?
<esden>
whitequark: \o/ :D
<mwk>
I mean
<electronic_eel>
yea
<mwk>
of course
<electronic_eel>
as I said, I always had a box of new ones
<mwk>
and getting a new gpu is kind of counter to the idea of having a collection of historic gpus
<electronic_eel>
makes having working old ones more valuable
<mwk>
I mean, they might not be fully working really
<mwk>
I don't actually run anything on them except for my RE tools
<mwk>
which probably don't stress a GPU the way running a game on it would
<electronic_eel>
I did not stress them at all, just running some linux X11 desktop stuff, no opengl or the like
<mwk>
hmm
<mwk>
maybe you just got bad luck
<mwk>
or the machine they were in had some problems with overheating or perhaps shit power supply?
<electronic_eel>
but the linux drivers back then were very limited, you couldn't do underclocking or similar
<electronic_eel>
the power supplies were usually of the better variety, but maybe overheating. we preferred passively cooled ones
<mwk>
I don't know how old you're talking, but before NV4x era, GPUs didn't even have temperature sensors
<electronic_eel>
I don't exactly remember. About 2000-2005 or something like that.
<mwk>
so definitely possible to damage in the wrong circumstances
<mwk>
yeah, that's before sensors
<mwk>
well, for nvidia at least, I don't know anything about any other GPUs
<electronic_eel>
you had very limited choice back then. nv provided binary drivers, and you could use matrox, but they were beginning to show their decline
<electronic_eel>
ati didn't have linux drivers at all back then IIRC
<mwk>
nv also provided "open source" drivers back then actually
<mwk>
the best they could do is get non-accelerated shit displayed on a screen (singular, forget about dual-head)
<electronic_eel>
ah, I was always using multihead
<mwk>
and "open source" in that someone run them through C preprocessor so that no informatively-named reg address constants are left in the code
<electronic_eel>
2 screens first, then 3 screens with a external hardware splitter (matrox triplehead 2 go or something like that)
<electronic_eel>
was a real leap ahead when nouveau became usable
<electronic_eel>
you said RE work. are you trying to support these cards in nouveau?
<mwk>
and a real slide backwards when it all went to shit
<electronic_eel>
I didn't follow development, was just using it
<mwk>
also, old cards are actually supported reasonably well in nouveau
<electronic_eel>
what is the problem?
<mwk>
it's the modern ones that are hopeless
<mwk>
well, there are two problems
<mwk>
one is that GPUs have gotten hellishly complex
<mwk>
and nouveau just doesn't have enough developers to handle that
<electronic_eel>
and no help from nvidia
<mwk>
sure, there are smart people in there, and they can deal with any single thing that nvidia throws at them... but not with all the things at once
<mwk>
and the second problem is that nvidia pretty much fucked nouveau over when they introduced secure boot on the GPU
<ZirconiumX>
That's not strictly true: Nvidia have contributed to Nouveau frequently. Just... not for any of the GPUs that matter
<mwk>
ZirconiumX: no
<mwk>
they are not contributing
<mwk>
they're throwing us fucking scraps
<mwk>
and doing PR out of that
<mwk>
fuck them
<electronic_eel>
why are they so hostile against it?
<mwk>
they're not really hostile
<ZirconiumX>
I thought they added mostly mobile GPU support?
<mwk>
they're honestly just indifferent
<electronic_eel>
but why develop secure boot stuff if you don't want to lock someone else out?
<sorear>
wasn't there some small change a couple months ago
<mwk>
electronic_eel: tbh nouveau is not important enough to lock us out
<mwk>
it's about the cloud and virtualization
<sorear>
the old excuse was "we're a hardware company, we subcontracted the GL driver and we can't share anything related to it"
<sorear>
the new excuse is probably something related to Grid
<mwk>
the idea is that a client with a dedicated GPU shouldn't be allowed to damage that GPU
<mwk>
or to persistently alter it (by, say, flashing the firmware)
<mwk>
hence, signed firmware
<mwk>
it started with the power management core, then sort-of spread to all firmwareful cores
<mwk>
and that this killed off nouveau — who cares? certainly not them
<electronic_eel>
why not introduce a fuse mechanism, you can blow it, upload your own firmware, but you are on your own then?
<whitequark>
because they don't care
<mwk>
electronic_eel: ^
<mwk>
they just don't give a fuck about you
<mwk>
which is, honestly, not the worst attitude a hardware company can have
<mwk>
I *wish* xilinx didn't give a fuck about open-source support, for example
<mwk>
ZirconiumX: and as for the mobile GPU support
<mwk>
the only reason they did that was because google forced them
<electronic_eel>
can you circumvent the secure boot thing by desoldering a flash chip? or is there some check code in the core itself?
<mwk>
and then they ended up shipping their own open source driver anyhow
<mwk>
electronic_eel: no
<mwk>
the flash is signed, and the key is burned into the GPU
<sorear>
"wish" as opposed to "hope" implies something that you know to be false, has Xilinx made threats?
<electronic_eel>
ok, that is a bit harder to defeat. you need a bug in their secure boot implementation. like ktemkin found for the switch
<sorear>
what's the signature algorithm
<mwk>
sorear: yes, and I've heard rumors of too-close-to-working projects actually disappearing after xilinx had a little chat with the authors
<JJJollyjim>
does the driver normally make the firmware somehow? I assumed you'd just use nvidia's firmware and communicate with it the same way they do
<mwk>
sorear: a variant of CMAC, AES-based
<sorear>
lmfao
<mwk>
secure as far as I know
<mwk>
except it's symmetric and you could probably extract the key from the GPU if you do enough bad things to it
<mwk>
but, well, they do have a few bugs in the secure boot implementation
<sorear>
so, cryptographically worthless as soon as anyone gets the verification key
<sorear>
you have how many billions and you coudln't implement rsa or ecc in your bootrom?
<mwk>
got they key, btw
<mwk>
but that took some time
<sorear>
anyway, toctou
<mwk>
sorear: toctou is not applicable
<mwk>
it's not flash that's signed, strictly speaking
<mwk>
it's the code within it
<mwk>
which is uploaded to a dedicated code RAM on-die before being checked
<sorear>
if they had enough space on the die for a dedicated code RAM why is there off-chip flash
<whitequark>
20:28 < sorear> you have how many billions and you coudln't implement rsa or ecc in your bootrom?
<whitequark>
i mean lots of companies couldn't implement rsa or ecc in bootrom
<whitequark>
that's not to say they didn't ship it anyway
<mwk>
sorear: because there's a lot of customization to be done for a specific graphics card
<JJJollyjim>
haha
<mwk>
and, you know, code may contain bugs, would be nice to be able to fix those
<electronic_eel>
so what is the problem if you got the key now?
<sorear>
I'm not proposing mask ROM, I'm proposing embedded flash
<electronic_eel>
sorear: maybe a process thing?
<sorear>
sorry, yes
<sorear>
ignore
<mwk>
electronic_eel: we only got the key recently (mostly due to many eyes looking at Falcon security thanks to nintendo switch), and that was enough time for nouveau to basically become a failed project
<mwk>
also, see reason 1, not enough developer power
<sorear>
the question above, why nouveau couldn't use the nvidia firmware as a black box, remains
<mwk>
we'd need to reimplement the firmware, and have a toolchain for it in the first place (custom ISA)
<mwk>
that takes time that we simply... don't have anymore
<mwk>
as for blackbox: legal
<mwk>
the firmware is part of the nvidia blob driver
<JJJollyjim>
oh damn
<mwk>
you don't have the license to use it other than as part of it
<mwk>
it's actually compiled into the .ko as a big array
<mwk>
somewhere in the data section
<electronic_eel>
hmm, but that is just for distributing the files, correct?
<sorear>
how does any of this work pre-boot
<electronic_eel>
couldn't you write a script that extracts it and the user has to download the blob from nvidia
<mwk>
sorear: one blob is booted from the flash
<mwk>
the blob is later replaced by the .ko
<sorear>
if I were going to offload complicated and unimportant features of a GPU to software, I would start with the VGA emulator
<whitequark>
you can't actually do that?
<mwk>
curiously enough, VGA emulator appears to actually be hardware
<mwk>
unless they changed it since I dumped nouveau
<electronic_eel>
what do you mean by "vga emulator" exactly? the stuff a classic bios needs to show the boot screen?
<mwk>
electronic_eel: good luck getting linux distros to sign off on this
<whitequark>
linux distros actually do this all the time?
<whitequark>
winetricks for example is in debian
<mwk>
remember, officially novueau is the linux driver for nvidia gpus
<mwk>
and it's a display driver, it has to *work*
<electronic_eel>
it just needs to show the url where to download the blob from
<electronic_eel>
or what script to call to do it for you
<sorear>
electronic_eel: classic bios but also a huge amount of DOS user-level software and older linux/X11/windows
<JJJollyjim>
The open source wifi driver for my old laptop worked like that
<mwk>
electronic_eel: yeah, that's doable
<mwk>
except now you have two paths in your driver
<sorear>
electronic_eel: the entire port-IO interface for setting video timings, configuring the vram aperture, palettes, ...
<mwk>
the firmwareful one which now requires user sign-off and internet connectivity
<mwk>
and the firmwareless one which still has to work at least well enough to get shit displayed on the screen
<sorear>
i guess in 2019 it might be possible to "sorry, our video card only works with UEFI operating systems"
<mwk>
and handling the whole mess is yet another spoonsink for the already overworked nouveau developers
<electronic_eel>
ok, but you don't need any 3d stuff in the basic one. and isn't the 3d stuff that takes most of the brains to develop?
<whitequark>
electronic_eel: you do
<whitequark>
desktop compositing
<mwk>
electronic_eel: anyway, my point is
<mwk>
sure, everything you're proposing is doable
<mwk>
any single thing you propose can be done
<mwk>
but a working display driver requires all of them
<mwk>
and we're just so fucking tired
<mwk>
you can pour years of your work into nouveau
<mwk>
and at the end of it, your results will be negative
<mwk>
because in the meantime nvidia made two new GPU generations
<electronic_eel>
yeah, that must be really frustrating, can fully understand it
<mwk>
and whatever hardware you spent years of your time on is now considered obsolete
<mwk>
fuck nvidia, and fuck nouveau as well, there's no hope for it
<JJJollyjim>
interested to see how linux support evolves with intel's discrete gpus
<mwk>
I still do RE work on nvidia gpus sometimes because it's honestly kind of interesting, but I limit myself to very old GPUs now
<mwk>
at least there's some hope of understanding those
<ZirconiumX>
mwk: I've been working on the PS2's GPU, which is a SGI-esque fixed-function pipeline. Even *that* is tricky to understand...
<mwk>
yeah well
<mwk>
I'm still not done with the NV1
<mwk>
though mostly because I'm going for bit-perfect emulation, I know pretty much all the interfaces already
<mwk>
(and NV1 is a 1995 device)
<electronic_eel>
ah, emulation. can you emulate it in software or are you using a fpga?
<mwk>
software
<mwk>
a qemu patch would be doable, though right now I just have a bunch of C functions that are verified by a test harness to produce same-as-hw results
<electronic_eel>
and the timing? is it good enough to have it not stutter in a game or something like that?
<mwk>
*shrug*
<electronic_eel>
wasn't screen refresh tracking a thing back then? you'd have to emulate it too
<mwk>
I'm in it just to understand the hardware, I don't care about games
<electronic_eel>
ah, ok, so you emulate just the output, not the timing.
<mwk>
if I have a C function that works the same as the hw, I consider the hw to be thoroughly reversed
<mwk>
yes
<mwk>
and anything nvidia made is new enough that nobody should really make anything depending on its timing
<mwk>
also uh, it's kind of hard to measure timing without getting a much better harness
<electronic_eel>
as i said, screen refresh tracking was common as vga was the only output back then
<electronic_eel>
didn't say it would be easy to do
<electronic_eel>
was just curious how much effort you put into it
<electronic_eel>
and correct timing would be considerable effort
<mwk>
heh
<mwk>
forget about it
<mwk>
there isn't such a thing as "correct" timing when you have a device that involves several asynchronous clock domains
<mwk>
even not including the pci bus and the rest of the system it is connected to
<electronic_eel>
yeah, the async clocks will always drift, even with the original
<mwk>
also you run into shit like some graphical operation being slower because a given DRAM bank was just closed because the scanout circuit needed to fetch a pixel line to dump to the DAC
<mwk>
just too much action at a distance
<electronic_eel>
but i guess the game developers still ran worst-case tests for certain operations and either slowed down the framerate or the game began to break down
<electronic_eel>
and the latter could happen if the timing of your emulation is too far off
<electronic_eel>
but if running games of that era is not your goal then that doesn't matter
<electronic_eel>
but still it would be a nice thing to try running doom on it
<mwk>
umm
<mwk>
you're aware that doom has no hardware acceleration support and treats all GPUs as a dumb framebuffer, correct?
<electronic_eel>
ah, yeah, right. it is a bit older than your nv1
<mwk>
and as for nv1
<mwk>
I suppose I could just collect all 5 games ever made for it and play them all
<mwk>
though playback-only is a lie, it has audio input
<mwk>
anyway, it has a midi synthesizer, which is the fun part
<sorear>
People made 5 games specifically for that? When did people stop targeting specific GPUs on PC software?
<mwk>
also, like a proper sound card, it also allows you to connect a joystick
<mwk>
which, for some reason, is handled by the DAC chip
<mwk>
sorear: when Direct3D happened
<mwk>
ie. soon after this thing
<electronic_eel>
sorear: read the wiki article, they used nurbs, not polygons
<mwk>
yes
<mwk>
getting this thing to render triangles is actually impossible
<mwk>
I tried
<electronic_eel>
lol
<mwk>
I mean, you can get it to draw triangular shapes, but not possible to texture them with any resemblance of sanity
<mwk>
also, the best part of this card is that it has a 128-byte EEPROM on it
<mwk>
which is exposed via the user APIs
<mwk>
and is used for 2 purposes
<mwk>
1) unique ID for DRM purposes in your NV1-specific game
<mwk>
2) storing user settings
<whitequark>
mwk: i'm sorry it uses what
<whitequark>
nurbs?!
<whitequark>
in hardware?!!
<mwk>
yes
<whitequark>
what the actual fuck
<mwk>
quadratic surfaces
<mwk>
it's really rather simple
<mwk>
whitequark: ... oh gods, it's going to be one of these times when I casually mention some cursed device, and you make a long twitter thread about its cursedness, isn't it?
<mwk>
ah well
<mwk>
anyway
<mwk>
the thing has a pretty standard boring 2D engine, which can do blit / fill / solid shape + raster ops
<mwk>
and a ... let's call it 3D engine
<mwk>
one of the 2D engine functions is drawing a solid-filled triangle
<mwk>
3D uses this function as a backend
<mwk>
so the 3D engine has exactly one operation available: draw a textured quad, with PoT texture size
<mwk>
you specify the quad to draw as 9 screen-space vertices: the 4 corners, the 4 edge centers, and the quad center
<mwk>
and it does a quadratic interpolation using those
<whitequark>
(thread) probably not, i don't understand nv1 nearly enough to do that
<mwk>
how it works is: it iterates through every texel in the texture one by one
<mwk>
interpolates the screen coordinates of its 4 corners using the quadratic equations implied by the 9 vertices you submitted
<mwk>
and draws the texel as two solid triangles via the 2D engine
<mwk>
done
<mwk>
I think I have a screenshot somewhere, hold on...
ExeciN has quit [Ping timeout: 240 seconds]
<sorear>
when you *really* want to make sure people mipmap
<mwk>
*sigh* of course I misplaced it
<mwk>
oh I found it
<mwk>
it's just on a drive stuffed into a decommisioned machine
<mwk>
awesome...
<mwk>
now where did I put that machine
<jschievink>
it draws each texel as two tris?¿
<mwk>
jschievink: yeah, as a solid quad, which is decomposed into two tris as usual
<mwk>
alright, found the machine with the screenshot
<mwk>
except I can't boot it because I don't have the *sigh* power cord
<electronic_eel>
it uses a specific custom power cord?
<mwk>
yeah...
<mwk>
it's an old nettop
<electronic_eel>
ah, ok, not a regular tower/desktop thing
<mwk>
I used it as my http server for some time and some of my screenshots ended up here
<mwk>
found the link in some channel logs
<mwk>
ahhh found it
<mwk>
let's boot it
<electronic_eel>
does it have an external power supply with some 12 to 24v dc going into it?
<mwk>
electronic_eel: yep
<mwk>
umm
<mwk>
what the fuck, why is it netbooting
<electronic_eel>
i use my bench supply for these cases, have a set of adapters from 4mm banana to a lot of the common and uncommon jacks
<mwk>
ah yes, and I decomissioned the machine because of a failed fan, so I better be quick about grabbing that file
<electronic_eel>
just put the duct of a vacuum cleaner near the heatsink, that is usually enough if it is not summer
<mwk>
was getting rid of the display engine from NV1, and making a new VGA-compatible one
<mwk>
you read that right, nvidia made a PC graphics card that was not, in fact, VGA compatible
<mwk>
there was some VGA emulation *in the video bios*
<mwk>
the NV1 had VGA registers, sure, but all they did was keep the last value that was written to them
<whitequark>
lol
<mwk>
and trigger a CPU interrupt that was supposed to call the driver and let it convert VGA register values to its native registers
<mwk>
which didn't actually support most of VGA features
<whitequark>
did intel hire the people who did that to make the PCH GPIO core
<mwk>
the display hardware only supports 256-color and 16-color modes with flat framebuffers
<mwk>
the vga planar memory access thing is emulated, so the 16-color modes from VGA work kind-of natively
<mwk>
as for text mode support... there is a dedicated piece of silicon in NV1 which renders text from the VGA framebuffer to the native framebuffer
ExeciN has quit [Ping timeout: 240 seconds]
<mwk>
it all kind of works out if you use bios calls to switch modes and don't use anything weird (like split screen, or 4-color modes)
<mwk>
but if you boot a protected mode OS and it tries to switch modes, everything falls apart
<mwk>
also, you may find some information that NV1 "is compatible with sound blaster"
<emily>
excited for the nv1 glasgow applet
<mwk>
it works the exact same way
<whitequark>
NO
<whitequark>
WILL NOT
<whitequark>
what interface does it have again? isa?
<emily>
plays a nice ditty while drawing some curvy bois
<whitequark>
vlb?
<emily>
>no >will not >immediately asks about interface
* whitequark
slaps emily around a bit with a large trout
<mwk>
the GPU just has some registers where it remembers whatever was last written to the SB regs
<mwk>
then calls the driver for help
<mwk>
whitequark: pci
<whitequark>
ugh no i refuse to work with pci
<whitequark>
it's too clever for its own good.
<whitequark>
pcie is fine. isa is also fine. pci, no
<mwk>
there are rumors of vlb, but I'm not sure if it actually exists
<mwk>
and by "rumors" I mean "I found the datasheet for the NV1 chip"
<mwk>
anyhow, back to the SB emulation... so I lied again about the DMA capabilities of the chip
<mwk>
it can do DMA for three things: the graphics engine screen-sysmem blit, the audio engine, and the Real Mode engine
<mwk>
you may be asking what the fuck is a Real Mode engine
<mwk>
so it refers to all the crazy shit used by the DOS TSR to emulate sound blaster, and by the BIOS to emulate VGA, and whatnot
<mwk>
and it has registers that allow you to request the card to perform a 4-byte DMA read or write to an arbitrary address
<mwk>
the DOS thing uses that to access arbitrary memory addresses without having to *gasp* switch to protected mode
<mwk>
if the game or whatever programs the "sound blaster" to DMA to/from >1MB memory, that's what it will use to transfer the data to the native buffer
<mwk>
(if you wonder why it has SGS-thomson branding on it, it's because in the early days nvidia did their GPUs in cooperation with them)
<mwk>
(they had some crazy agreement that half the products used one branding, half used the other... like, the DRAM version of nv1 was sold under SGS branding, the VRAM version was sold under nvidia branding)
<mwk>
(and by "branding" I mean *PCI IDs* as well)