m_t has quit [Quit: Leaving]
X-Scale has quit [Ping timeout: 240 seconds]
<cr1901_modern> rqou: Good stuff!
X-Scale has joined ##openfpga
unixb0y has quit [Ping timeout: 245 seconds]
unixb0y has joined ##openfpga
digshadow has quit [Quit: Leaving.]
<awygle> Why do unplanned naps always feel like I had to crawl out of hell to wake up :-/
<qu1j0t3> IT'S YOUR BODY SENDING YOU A MESSAGE
<awygle> well yeah but wasn't putting me to sleep involuntarily sufficient?
<qu1j0t3> well, you're supposed to reflect on your unhealthy lifestyle
<qu1j0t3> is it the weather? i had an urge to nap today, i don't often get it, except in the heat
<awygle> if my body wants me to get more sleep it needs to figure out how to be tired at night
<qu1j0t3> and i generally don't because i hate the disoriented feeling of waking up in the afternoon
<awygle> I think it's that the weather is keeping me from sleeping well tbh
<qu1j0t3> yeah
<awygle> I bought an air conditioner but it's not here yet (because I'm not as cool as whitequark)
<whitequark> you're definitely not as cool as you would be with an air conditioner
<awygle> also true
<awygle> hey whitequark, how much better is two hoses to outside than one hose to outside for a portable ac unit?
scrts has quit [Ping timeout: 260 seconds]
<whitequark> portable ac units are crap
<whitequark> vapor compression ones are -far- more efficient
<openfpga-github> [Glasgow] whitequark pushed 2 new commits to master: https://github.com/whitequark/Glasgow/compare/6cb4f9972d68...b7ce28fa03bf
<openfpga-github> Glasgow/master b7ce28f whitequark: Add a TRACE log level and log all port and USB I/O using it.
<openfpga-github> Glasgow/master d37c172 whitequark: Update libfx2.
<whitequark> oh you mean two different portable ac units
<whitequark> not sure
<whitequark> i'd need to look into it
digshadow has joined ##openfpga
<sorear> What else is there besides vapor compression?
<whitequark> evaporation, for example
<whitequark> absorption
<sorear> And where is the portable/nonportable line drawn?
<whitequark> portable is anything that isn't screwed down onto a wall
scrts has joined ##openfpga
ZombieChicken has joined ##openfpga
<awygle> yeah this doesn't say anything about operating principle
<awygle> but I can't screw holes in the wall so *shrug*
scrts has quit [Ping timeout: 240 seconds]
<awygle> I paid like 50$ for an inlet hose instead of just drawing from the room, hope it was worth it
<awygle> fortunately this place is insulated like a refrigerator so it'll probably be fine regardless
ZombieChicken has quit [Quit: Have a nice day]
scrts has joined ##openfpga
digshadow has quit [Ping timeout: 244 seconds]
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
<whitequark> wtf
<whitequark> I found a bug in python-libusb1
<awygle> ...wow
<whitequark> that code could never have worked
<whitequark> it just segfaults on process exit
<rqou> <troll> so? the process is already exiting :P
<rqou> although i'm curious what the bug is
<rqou> hmm, i've never noticed crashes like that before
<whitequark> that's because next to no one uses async libusb functions lol
<awygle> i vaguely feel like i've run into this but as rqou said the process was ending anyway
<awygle> it could easily have been a different bug though
<awygle> i bet "cleaning up badly" is a very common class of bug
<whitequark> okay, glasgow now supports async USB I/O
scrts has quit [Ping timeout: 244 seconds]
digshadow has joined ##openfpga
<whitequark> let me, uh, clean this up
<whitequark> as you may have guessed, i needed an usb-uart and can't be arsed to find one
<awygle> relatable content
<kc8apf> whitequark: I started using parcel for my web 3.1alpha45 projects
<kc8apf> cuts out all the webpack bullshit
<kc8apf> doesn't make the rest of the ecosystem any better but....small victories
<awygle> wtf is "web 3.1alpha45"
<awygle> i hope to god that's a joke lol
<whitequark> >self.get_out_transfer()
<whitequark> get_out
<kc8apf> me being snippy about web devs
<awygle> okay good
<rqou> yeah, i'm really disappointed that afaict es6 modules still haven't happened
<awygle> it says something about the ecosystem that that's like, mostly believable as a thing
<rqou> originally it was supposed to be in es6
<awygle> hence the name
<kc8apf> rqou: well, you just use babel via parcel and hope
<rqou> and then it got deferred or something??
<rqou> and then some bikeshed happened about syntax
<awygle> are they es7 modules now?
<rqou> and now i think it's finally happening for real
<rqou> i don't know
<kc8apf> isn't everyone moving to typescript now?
<rqou> SIMD got killed too
<kc8apf> or is Dart again?
<whitequark> lol Dart
<whitequark> no, it's typescript
<whitequark> and ts is really cool
<awygle> typescript seems relatively sane yeah
<whitequark> from the language design point of view anyway
<whitequark> never used it
<rqou> from prior experiences i'm very wary of all of these transpilers
<rqou> at this point i'd probably just go with es6-flavored VanillaJS
<rqou> :P
<whitequark> the only good way to use the word "transpile" is when it relates to hugs
<whitequark> everything else is just a compiler
<awygle> what is VanillaJS or Vanilla.js? is that a real framework thing or more snark?
<rqou> at one point it was snark
* awygle must be getting old
<rqou> but apparently somebody turned it into a real thing??!
<whitequark> wtf
<rqou> no wait
<rqou> it is a joke
<rqou> the joke just got more elaborate
* awygle sighs
<kc8apf> parcel + Vue makes for a tolerable environment
<rqou> at this point i would probably hesitate to adopt any new framework
<rqou> it was pretty "fun" getting burned last time
<whitequark> the solution to too many frameworks is one more framework
<whitequark> obviously.
<rqou> there was a joke "meta package manager" at one point in time
<kc8apf> Vue is 90% webcomponents in a backward compatible form
<rqou> back when there was npm and then some other repo that people used for client-side code
<kc8apf> less framework and more a sane way to encapsulate HTML + JS + CSS for widgets into a thing
<rqou> i thought web components never shipped thanks to perpetual bikeshedding between apple and either google or mozilla?
<kc8apf> dunno.
<kc8apf> Polymer is a public thing built on webcomponents but it stucks
<awygle> what is webcomponents
<kc8apf> let's you define custom HTML tags
<awygle> ... why tho
<awygle> (not particularly a serious question)
<kc8apf> modular design
<rqou> so that the web can finally have composability for once?
<rqou> seriously, why are web people particularly bad at this?
<whitequark> libusb1: if self.__doomed: raise DoomedTransferError('Cannot reuse a doomed transfer')
<awygle> i am deeply uninformed about the web. i have zero idea how anything works at the level of browsers.
<whitequark> very gothic
<whitequark> awygle: it mostly doesn't
<rqou> I've learned that everything i expected to work a certain way doesn't
<rqou> e.g. every time i write an algorithm that touches DOM, multiply another `n` into the big-O runtime
<rqou> (housemate interned at Mozilla and told me how everything i expected was wrong)
<awygle> the DOM in general seems... odd
<awygle> as a design
<rqou> apparently a huge problem with my intuition is that the JS JIT has absolutely no visibility into DOM access
<awygle> again, deeply ignorant, so not saying it's bad, it's just not intuitive to me
<whitequark> rqou: lol
<rqou> so many things i expect to be fast aren't
<whitequark> that's
<whitequark> that's sort of true
<whitequark> it's because you interned at mozilla.
<rqou> not me
<rqou> my housemate
<whitequark> v8 doesn't really have this problem, and this is also why you don't need asm.js on v8
<whitequark> i mean a special asm.js mode
<rqou> hmm really?
<whitequark> regular v8 mode produces native code that's just as fast as mozilla's special-purpose compiler, AND you can just randomly access DOM throughout it
<whitequark> especially with turbofan
<whitequark> (but it was pretty good on crankshaft too)
<whitequark> @mraleph wrote a few articles about this
<rqou> i thought the whole point of the HolyJIT experiment is to give the JS side more visibility into what's going on on the DOM side
<whitequark> holyjit?
<whitequark> oh yeah that's similar to what Graal does
<whitequark> from the looks of it, great work
<whitequark> but it's not directly related to DOM
<rqou> yeah apparently not
<rqou> i was told that that's apparently going to become theoretically possible in the future
<rqou> inlining/optimizing DOM access
<whitequark> right, that's true, but from what i know, that's a really tall order
<whitequark> you have to align many more stars
<rqou> but then v8 probably doesn't fix this problem either
<rqou> apparently current JITs don't handle things like this well
<rqou> e.g. my intuition tends to be "yeah, i can read this property tens of thousands of times, i never mutated it"
<rqou> combined with me poking properties that cause a re-layout to happen
<whitequark> no, I was referring to a different problem
<whitequark> I didn't understand exactly what you were asking
<whitequark> I can't believe it worked the first time
<whitequark> both the UART and the async I/O...
<rqou> anyways, i was told that (at least on Firefox) you can get huge performance improvements by just buffering all the changes that your code wanted to make and then doing all the DOM poking all at once
<awygle> the web is video games from 1995
<rqou> meaning?
<awygle> idk something about batching up draw calls
<whitequark> uh
<whitequark> you have to do that today
<awygle> yeah i didn't really think that through
<whitequark> you did not have to do that in 1995 and that killed perf on modern drivers
<whitequark> also, opengl is horribly designed
<awygle> yeah it's a bummer
<awygle> and vulkan appears to be "okay you don't like our API design? do it yourself then"
<awygle> which is not a _bad_ choice but promises to be a lot of work in the short term
<awygle> whitequark: should i leave the Glasgow symbol library in the repo and sym-lib-table even though we don't reference anything in it currently?
<awygle> we probably will again during rev c
<rqou> yeah, I don't understand how anybody actually learns opengl
<rqou> you either follow the NeHe tutorials which I'm told are really outdated, or you have a giant pile of tutorials that are 1) draw a triangle 2) draw the rest of the fucking owl
<whitequark> wagle: sure
<whitequark> erm
<whitequark> awygle: sure
<awygle> lmao
<whitequark> not sure how irssi mangled that
<whitequark> rqou: well i hired a guy
<awygle> that's more or less how people (mis)pronounce my last name
<whitequark> to do opengl in solvespace
<awygle> rqou: this article helped me enormously with the modern pipeline stuff http://www.codinglabs.net/article_world_view_projection_matrix.aspx
<whitequark> vulkan is more like opengl construction kit than an api
<awygle> people were like "I GOT SOME SHADERS AND SOME MATRICES" and i didn't... get it
<whitequark> you don't program applications against vulkan
<awygle> i still don't, to be frank, but i'm closer than i was
<rqou> i think I complained about this before, but my experience is that all graphics tutorials end up just being some combination of linear algebra tutorial, operating systems tutorial, and/or computer architecture tutorial
<rqou> supposedly the set of people already reasonably familiar with all of these topics but knows absolutely nothing about modern graphics APIs is very very small
<rqou> awygle: that's _also_ a linear algebra tutorial
<awygle> yes, it is
<awygle> but it explains the connection to graphics
<awygle> or did to me anyway
<rqou> but that's not the part i don't know :P
<awygle> i knew how to multiply matrices, just not _why_ to multiply them in this case
<awygle> well good for you :p
<rqou> all i know right now is "glBegin and magic happens"
<awygle> you make a list of the vertices, say "this list of vertices i'm going to hand you represents triangles", and pass the list to the gpu
<awygle> then your shaders execute
<awygle> you don't use glBegin
<awygle> (that's the old "immediate-mode" pipeline which doesn't exist after like OpenGL 3 iirc)
<rqou> nobody seems to have a good tutorial explaining how e.g. glVertex3f or similar eventually turn into commands in a ringbuffer for the GPU
<awygle> you don't do that anymore tho
<whitequark> they don't because the way graphics drivers manage to get any performance out of glBegin() is insanely complicated
<whitequark> which is why it isn't used anymore
<rqou> and when i pass the list of triangles, does it DMA into GPU memory? immediately? or does it fetch data from main memory over the PCIe bus? how do i control what i get?
<whitequark> you pass a parameter for that
<whitequark> also, not all GPUs even -have onboard RAM
<whitequark> so you get less control, but you do get some
<rqou> right, my complaint is that nobody seems to write tutorials that focus on these details
<whitequark> that's because no one except driver devs actually know them
<whitequark> and it's certainly not tutorial material
<rqou> everybody seems to really like explaining how linear algebra works or explaining how to link libpng
<awygle> the answer is "it depends", always
<whitequark> in general, if you want your game to work well, you hire a guy from nvidia who takes a debug build of their gpu driver and goes through your shitty code
<whitequark> and then a guy from amd
<whitequark> and then one from intel, maybe
<awygle> i have a friend who literally does this for intel
<whitequark> this is e.g. what valve did when they ported tf to linux
<awygle> "hi $GAME_STUDIO write your code this way and it will be good"
<rqou> or at best explaining how to write memory pool allocators (which is most of the Vulkan tutorials I've found)
Bike has quit [Quit: Lost terminal]
<rqou> hmm, my approach to any topic has always been to try and understand how it works one or more levels of abstraction lower
<rqou> apparently this is completely the opposite of how "graphics people" work?
m_w has joined ##openfpga
<whitequark> you probably can't understand how gpus really work
<whitequark> not because they're intrinsically complicated but more because they're giant piles of hacks and shit
<awygle> or both, maybe
<whitequark> like i'm not sure exactly how much code in modern graphics drivers is basically "if(running_game_a) replace_shaders_with_non_shitty_version()" but it's definitely more than 50%
<whitequark> yes gpu drivers literally ship with fixed shaders for like gta and so on
<whitequark> also all opengl drivers still check for one specific doom version and return a limited number of opengl extensions to avoid overflowing a buffer on stack that it has
<awygle> iiuc this is one of the reasons for vulkan, because it's lower level it's easier to write drivers for (or alternately it pushes more responsibility to engine devs)?
<whitequark> both
<awygle> yeah two sides of the coin
<whitequark> vulkan actually exposes the way the gpu works, or at least does it to a much larger extent than opengl
<whitequark> but, well, you get to write low-level code against the gpu, and that fucking sucks
<rqou> so far most of the tutorials on Vulkan that I've found seem to focus on building memory allocators and seems to assume that you in general understand "how graphics works" for all the other bits
<rqou> which is also useless. if i wanted a tutorial on memory allocators i can just research that topic specifically
<rqou> nobody seems to bother explaining the actual "how 2 graphics" bits
<awygle> i think you don't know what you want to know
<awygle> or else you're not doing a great of conveying it
<rqou> honestly I'd really like a tutorial that starts with "we're going to start by using libpci or whatever to steal access to an Intel/AMD GPU and we're going to poke its ringbuffers directly"
<whitequark> that's not a tutorial
<whitequark> that's called documentation on writing graphics drivers
<whitequark> and uh, go read either mesa source code or i915 support in directfb (or what was it)
<rqou> you can then build up to programming again an api like Vulkan
<whitequark> why the fuck would anyone want to actually do that
<whitequark> you don't have the NDA'd docs for the GPU and you don't have access to all the errata and suboptimal performance cases that will make your stuff work way too slowly
<whitequark> or break
<rqou> you wouldn't want to do that in a real program
<whitequark> then don't call it a "tutorial"
<whitequark> tutorials explain how to write real programs
<rqou> it's specifically to go under the hood to explain how the pieces fit together
<whitequark> they don't
<whitequark> the GPU driver is all the hot glue that keeps the mess from falling apart
<whitequark> you really don't want to explain that, in part because when it completely changes in two years, people will still cite your now incorrect info for decades
<rqou> i mean, that happens anyways (e.g. the NeHe tutorials)
<openfpga-github> [Glasgow] awygle pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/f44bf51c2a596be1b9d44b84e8a14381a43c4fbc
<openfpga-github> Glasgow/master f44bf51 Andrew Wygle: Use upstream FPGA symbol
<rqou> anyways, in my "i wish this existed" not-a-tutorial, it would conclude with how to program against Vulkan
<whitequark> where do you get these weird-ass ideas lol
<awygle> whitequark: did you select resistors for this by "go to mouser sort by cheapest" or some other method?
<rqou> i like to see how the pieces work internally
<rqou> why is that weird?
<whitequark> awygle: former
<whitequark> i think i slightly adjusted it to try and stay within one series
<whitequark> and one vendor
<awygle> rqou: i more-or-less agree with you (this is why i can't web) but i've resigned myself to pretending vulkan and shaders and etc are as low as it gets
<whitequark> rqou: it is weird in case of gpus
<whitequark> well, i guess it isn't if you don't know anything about gpus
<openfpga-github> [Glasgow] awygle commented on issue #51: Because it's an open drain output, 300 mV is Vol in this case - the voltage for a logic 0. The high voltage will be the full VIO voltage. https://github.com/whitequark/Glasgow/issues/51#issuecomment-403698181
<rqou> i mean, EE/CS courses go into how to build 5-stage RISC pipelines and all the stuff above that like compilers and operating systems (although the explanations may be oversimplified)
scrts has joined ##openfpga
<rqou> why can't this exist for GPUs?
<awygle> rqou: think of it like this - you're sitting at IP, going "I want to know what the lower layer is like", but there are N lower layers, all different.
<whitequark> um, this exists
<whitequark> courses that go into building toy GPUs, just like there are courses that build toy CPUs
<whitequark> you know, in-order, scalar...
<whitequark> you don't go on the web and ask "i want to learn programming simd, now how do i build an out-of-order superscalar cpu this will run on"
<whitequark> abstractions exist for a reason
<rqou> sure, and i definitely use abstractions too, but i find that knowing what's under the abstraction is usually helpful
<rqou> also, i haven't seen a toy GPU course that also talks about the magic in the driver layer or opengl layer
<rqou> awygle: but at $FANCY_SCHOOL, you really can drill down from TCP/IP to device physics
<awygle> rqou: yes but there's a big gap between "this is NRZ encoding" and "here's how PPP, 802.3, 802.11, ATM, etc etc etc all work"
<awygle> my understanding is that GPUs aren't centralized enough so you can learn 802.3 and say "eh good enough"
<awygle> also, not documented enough so that you can learn anything lol
<whitequark> most of the magic in driver layer and device layer is NDAd, mostly because vendors are ashamed of producing this abomination
<rqou> but Intel and AMD have open-source drivers
<whitequark> lol
<rqou> they at least work somewhat
<whitequark> I think in some of the Intel's drivers they remove all comments before mainlining
<whitequark> and possibly rename registers to uninformative names
<rqou> i thought that was Nvidia
<awygle> can someone please explain to me why kicad has a table view of fields that's read-only and then a text box for editing instead of just making the table view editable
<awygle> like why
<whitequark> pretty sure I've seen that in intel too
<whitequark> awygle: open-source UI \o/
<awygle> this has to be a wxWidgets thing
<rqou> I'm pretty sure not Intel, somebody made a big deal a while back that intel released a ton of GPU documentation
<rqou> supposedly enough to actually write a new driver from scratch
<rqou> maybe it was AMD, but then you just need to poke marcan about those data files he managed to find
<openfpga-github> [Glasgow] awygle closed issue #51: Make SYNC pullup smaller https://github.com/whitequark/Glasgow/issues/51
scrts has quit [Ping timeout: 240 seconds]
<rqou> whitequark: how do people do GPU optimizations if nobody ever bothers to peek under the abstractions?
<rqou> or is this why i see people like Fiora be sad all the time?
<whitequark> yes
<openfpga-github> [Glasgow] awygle closed issue #61: Update to use upstream symbols/footprints https://github.com/whitequark/Glasgow/issues/61
<awygle> okay, i've accomplished some stuff for once
<awygle> whitequark: i believe this is a Rev B now. please take a look and clean stuff up if necessary, as you have time. i'll do another pass tomorrow as well.
<whitequark> whoa nice, thanks!
* awygle is a sleepy boi
<awygle> nite all
<openfpga-github> [libfx2] whitequark pushed 1 new commit to master: https://github.com/whitequark/libfx2/commit/9dac8a65e313225d30a4ea22dfac0da958146797
<openfpga-github> libfx2/master 9dac8a6 whitequark: Implement support for polling USB fds, alongside synchronous calls.
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/228549f3ab5493fc742d7f840265423360cae455
<openfpga-github> Glasgow/master 228549f whitequark: Implement asynchronous USB I/O via get_port(async=True).
<whitequark> ah fuck
<whitequark> yet another time i get screwed by pullups
<whitequark> rev C is needed urgently
<rqou> lol
scrts has joined ##openfpga
scrts has quit [Ping timeout: 264 seconds]
scrts has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
scrts has quit [Ping timeout: 264 seconds]
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/24e6f58d9435dff022703c534478a30c5bbc7e63
<openfpga-github> Glasgow/master 24e6f58 whitequark: Implement an UART applet.
<whitequark> awygle: we still need to figure out the values of slew rate limiting R's
<openfpga-github> [Glasgow] whitequark commented on issue #35: Thanks! https://github.com/whitequark/Glasgow/issues/35#issuecomment-406776476
<rqou> ugh, lots of fun when i accidentally mix py2 and py3
<openfpga-github> [Glasgow] whitequark pushed 3 new commits to master: https://github.com/whitequark/Glasgow/compare/24e6f58d9435...ef4e170ccdcc
<openfpga-github> Glasgow/master ef4e170 whitequark: Add fabrication outputs for revB....
<openfpga-github> Glasgow/master 9f49aaa whitequark: Update MPN on schematic.
<openfpga-github> Glasgow/master b471993 whitequark: Update revision on schematic.
<openfpga-github> [Glasgow] whitequark closed issue #35: Slew rate limiting resistors https://github.com/whitequark/Glasgow/issues/35
<openfpga-github> [Glasgow] whitequark commented on issue #28: @awygle That symbol is now merged. https://github.com/whitequark/Glasgow/issues/28#issuecomment-406778257
<openfpga-github> [Glasgow] whitequark opened issue #62: Use USB type C connector https://github.com/whitequark/Glasgow/issues/62
<rqou> whitequark: you actually intend to use usb C?
<rqou> i assume in a legacy mode only?
scrts has joined ##openfpga
bitd has joined ##openfpga
scrts has quit [Ping timeout: 248 seconds]
rvense has quit [Ping timeout: 256 seconds]
rvense has joined ##openfpga
<whitequark> why not
<whitequark> and yeah
bitd has quit [Ping timeout: 265 seconds]
bitd has joined ##openfpga
<whitequark> huh, so I poked this router on its serial console
<whitequark> turns out zyxel wrote the entire linux userspace as one big c++ thing with its own shell
<whitequark> and, shockingly, it's actually good
indy has quit [Ping timeout: 240 seconds]
user10032 has joined ##openfpga
indy has joined ##openfpga
<marcan> rqou: GPUs aren't *that* complicated once you strip away all the fluff anyway
<marcan> it's just the usual "this is a big chip with a lot of knobs you have to tweak to get stuff going" stuff, like most SoCs
<marcan> seeing stuff like the amd microcode disasm was fun though
nurelin has joined ##openfpga
<marcan> tbh if you're trying to learn how GPUs work and don't mind starting with something a bit retro I would actually recommend looking at the GameCube/Wii GPU
nurelin has quit [Client Quit]
<marcan> it lacks shaders (instead it has a nominally fixed-function fragment processing pipeline that you could call an up to 16-instruction fragment shader)
<marcan> and no vertex processing beyond a basic transform or so
<marcan> but it doesn't have microcode or any of that crap, requires little setup, and is vaguely documented (and you can try to read libogc source code to work it out)
nurelin has joined ##openfpga
<marcan> and Dolphin emulates it so you can play with it with just a computer
<marcan> the programming model is similar to how modern GPUs work (ring buffer queue with indirect buffers etc)
<marcan> t
<marcan> (though the *CPU* has a hack they added to optimise pushing words to the buffer, it basically does write-combining in the CPU itself and then bursts stuff out)
rohitksingh has joined ##openfpga
<marcan> you could also try doing some raw libdrm stuff on linux. the kenel basically takes care of memory management, context switching, and low level setup
<marcan> but then userspace gets full control of the actual command buffers used for drawing stuff on screen
<marcan> so there's value in learning that chunk of the stack first without having to start with raw pci pokes
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
indy has joined ##openfpga
nurelin has quit [Ping timeout: 256 seconds]
Bike has joined ##openfpga
m_t has joined ##openfpga
bitd has quit [Ping timeout: 245 seconds]
bitd has joined ##openfpga
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
Bike has quit [Ping timeout: 264 seconds]
GenTooMan has joined ##openfpga
scrts has joined ##openfpga
ZombieChicken has joined ##openfpga
<sorear> I read a neat book on the design of graphics subsystems in high school. Printed ~1990 but a surprising number of trends are extrapolatable
<pie_> so post
<pie_> *do
<pie_> xD
<sorear> Don’t have it anymore
bitd has quit [Ping timeout: 265 seconds]
gruetzkopf has quit [Read error: Connection reset by peer]
rohitksingh has quit [Quit: Leaving.]
bitd has joined ##openfpga
gruetzkopf has joined ##openfpga
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined ##openfpga
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined ##openfpga
m_t has quit [Quit: Leaving]
Bike has joined ##openfpga
<awygle> whitequark: I personally love usb c but it may be less appealing to others
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
<gruetzkopf> i've seen very few correct usb-c implementations
<gruetzkopf> but i like it
kmehall has quit [Quit: No Ping reply in 180 seconds.]
kmehall has joined ##openfpga
<awygle> gruetzkopf: would you prefer it or micro on Glasgow?
<daveshah> I would go for type-C
<daveshah> Partly feeling excited about type-C because of the new tinyfpga board
<awygle> lol yes
<awygle> I was just sitting here imagining Glasgow-D with USB 3.0 on an ecp5-5g 85k
<daveshah> :D
<awygle> (someday lol)
<gruetzkopf> i've been staring at implementing CC protocol myself in digital logic
<gruetzkopf> also: usb3.2 with 2*Gen2 links in one cable
<gruetzkopf> 20GBit/s USB
<awygle> won't fit in an ecp5 lol
<gruetzkopf> hehe .D
<awygle> cyclone 10 gx
<awygle> (cough rqou :-P)
<gruetzkopf> 2*5 is also allowed, which gets you 10 without the high-speed phy
<awygle> yup yup
bitd has quit [Ping timeout: 265 seconds]
<awygle> much better match to available serdes than xaui/10gbe imo
<awygle> too bad the rest of the stack seems to be such a mess
<gruetzkopf> like i said, i'm looking into the CC protocol and PD 3.0
<gruetzkopf> (mostly to build the one true portable battery, that supports 5/9/12/15/20V at 5A
<gruetzkopf> most that are available miss at least one of (12|15)
<gruetzkopf> or only provide 2A at 5V
<awygle> that sounds cool
<awygle> surely doesn't need 20gbps of throughput tho :-P
<gruetzkopf> hmm, why not?
<awygle> good marketing copy tho. "world's fastest battery! 20gbps!"
<gruetzkopf> connect 2 laptops, tunnel usb, run cdc-ether
<sorear> do you have the 100 Wh rule over there too?
bitd has joined ##openfpga
bitd has quit [Remote host closed the connection]
<gruetzkopf> for air travel
<gruetzkopf> iirc that's a IATA rule, mostly
user10032 has quit [Quit: Leaving]
<sorear> i guess the much higher mode share of intercity rail might affect the market for batteries?
<sorear> here, laptops and portable batteries over 100 Wh basically aren't sold because you can't take them on planes
<gruetzkopf> iirc jn__ has a >>100Wh battery for his laptop
<gruetzkopf> many new trains have outlets
<gruetzkopf> (such as this stadler FLIRT-3 EMU i'm currently in)
digshadow1 has joined ##openfpga
<mithro> Morning everyone
rohitksingh has quit [Quit: Leaving.]
<mithro> This new Numato board seems pretty good - still trying to find out if the mDP ports can /actually/ be used for mDP...
digshadow has quit [Ping timeout: 276 seconds]
<daveshah> mithro: link pls?
<daveshah> I'd love to write a DisplayPort core one day, it's been on my todo list for two years now
<daveshah> you don't happen to have a schematic?
<mithro> daveshah: Nope not yet...
<mithro> rohit has been working on HDMI2USB support for it at https://github.com/timvideos/HDMI2USB-litex-firmware/compare/master...rohitk-singh:mimas_a7
<mithro> daveshah: Have you seen Hamster's DisplayPort core?
<daveshah> mithro: yeah, that's transmit, right?
<mithro> Yeap
<daveshah> I am tempted to do an Rx at some point
<mithro> Sadly it's VHDL
<mithro> But I've been slowly trying to convince him to move to Verilog :-P
<awygle> Oh hey netbsd still exists
<cr1901_modern> awygle: Still? I used it as my primary OS for a few weeks when 7 came out (2015 around this time) :P. It was usable. I could even run ISE Webpack on it.
<cr1901_modern> Mainly excited about kernel audio mixing b/c it means I can tell PA to go f*** itself
<awygle> I forgot about it tbh. I would have listed free, open, and dragonfly.
<cr1901_modern> the other two I know of are mir and edge. But I couldn't tell you the differences
<openfpga-github> [Glasgow] whitequark pushed 2 new commits to master: https://github.com/whitequark/Glasgow/compare/ef4e170ccdcc...1cee8b9b43ab
<openfpga-github> Glasgow/master 1cee8b9 whitequark: Re-enable ACT LED disabled in firmware by accident.
<openfpga-github> Glasgow/master 0998193 whitequark: UART: improve TTY handling....
soylentyellow_ has joined ##openfpga
indy has quit [Ping timeout: 244 seconds]
soylentyellow__ has quit [Ping timeout: 256 seconds]
<mithro> cr1901_modern: But you still run Windows too, so yah know? :-P
* awygle runs windows >50% of the time
<awygle> the new kicad release download is 1GB in size >_< i assume because of 3d models
<daveshah> Thanx
<daveshah> Look pretty clearly like properly wired DP ports
<awygle> how fast does dp have to be?
<daveshah> Starts from 1.62Gbps/lane
<daveshah> then 2.7, 5.4 or 8.1
<awygle> ah
<daveshah> you can also run VESA DSC on top of that for higher effective data rates
<awygle> just wanted to make sure it was kosher with the slower GTPs on the -1 artix
<rqou> awesome: `bash: /bin/mv: Argument list too long`
<awygle> xargs brah
<rqou> how will that help me?
<sorear> Long paths or lots of files?
<rqou> lots of files
<rqou> it was literally `mv <glob> dir/`
soylentyellow__ has joined ##openfpga
soylentyellow_ has quit [Ping timeout: 260 seconds]
<awygle> xargs breaks the command up so that doesn't happen
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined ##openfpga
ZombieChicken has quit [Quit: Have a nice day]
noobineer has joined ##openfpga
noobineer has quit [Ping timeout: 240 seconds]
<whitequark> [ERROR] glasgow.applet.selftest: self-test: FAIL
<whitequark> [ERROR] glasgow.applet.selftest: pins-ext: stuck low: B5
<whitequark> [ERROR] glasgow.applet.selftest: pins-ext: shorted: A0 A2
<openfpga-github> [Glasgow] whitequark closed issue #56: Implement a self-test routine checking for solder bridges https://github.com/whitequark/Glasgow/issues/56
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined ##openfpga
<awygle> that's cool
m_t has joined ##openfpga
m4gul0_ has joined ##openfpga
ZombieChicken has joined ##openfpga
Miyu has joined ##openfpga
<azonenberg> ooh
<azonenberg> That remidns me, at some poit
<azonenberg> i need to implement jtag boundary scan support
<azonenberg> in jtaghal
<azonenberg> i've literally done everything but EXTEST at this point :p
<Miyu> :>
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/a41409e0ea347e7b5ea672714a95a73f0987966e
<openfpga-github> Glasgow/master a41409e whitequark: selftest applet: add pins-loop and voltage modes.
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined ##openfpga
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined ##openfpga
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined ##openfpga
gruetzkopf is now known as Guest57955
<mithro> It's annoying that the twinkie is so hard to source - https://sites.google.com/a/chromium.org/dev/chromium-os/twinkie
<daveshah> mithro: interesting, thanks
<daveshah> I think doing CC on a softcore would make most sense
<daveshah> Looks like everything is in the ec repo, although it might be a bit of work to untangle into a standalone open core
<mithro> daveshah: Yeah - ChromeOS people like doing their own thing quite a lot :-/
<mithro> daveshah: Definitely should be software which runs on a soft-core
ZombieChicken has quit [Remote host closed the connection]
Miyu has quit [Ping timeout: 264 seconds]
_whitelogger has joined ##openfpga
m_w has quit [Quit: leaving]