<rqou>
i'm surprised i never came across it before
<cyrozap>
whitequark: Kind of? Not in any official capacity, at least.
<rqou>
it's the best "how does all the sh*t fit together" i've seen so far
<cyrozap>
whitequark: I was trying to keep this a little on the DL, because I don't have anything working yet, and I don't want to get anyone's hopes up with an announcement in #lima before I have at least a PoC Gallium driver.
<cyrozap>
Well, actually I do kind of have a skeleton of a Gallium driver working. I can run es2_info and get the Kernel driver + hardware info, at least.
<rqou>
why do modern LCDs still use HSYNC/VSYNC?
<rqou>
it would be interesting to consider a potential LCD interface with RAS/CAS strobes instead, allowing for interesting hacks like variable refresh rate in different regions of the screen
<cyrozap>
The really tricky part is going to be the compiler. Originally, I was really hoping I would be able to start with a working compiler, strip out all the higher level compiler bits (because Gallium takes care of that), leaving the IR stuff to wedge into the Gallium driver. Unfortunately, with all due respect to cwabbott (I wouldn't be working on this if he hadn't started his work on the compiler), it's a
<cyrozap>
tangled mess of uncommented code that segfaults when you try to get it to compile certain shaders, and is incredibly hard to debug.
<cyrozap>
rqou: Because legacy interfaces are hard to kill
<rqou>
re shader compiler: you mean no worse than the existing implementation? :P
<rqou>
wtf according to one of the slide decks FBDEV has more code than DRM
<rqou>
how is that possible?
<whitequark>
DRM is basically shuffling buffers around, FBDEV has all the hairy setup code?
<whitequark>
aiui the bulk of complexity of 3d drivers is in the userspace component
<rqou>
setup code like what?
<whitequark>
modesetting?
<rqou>
i always thought the way FBDEV basically worked was just REG_SCANOUT_ADDR = <some buffer>
<whitequark>
well it has to negotiate link, handle rotation, scrolling...
<rqou>
can FBDEV devices even do modesetting?
<whitequark>
KMS.
<rqou>
but that's part of DRM only?
<whitequark>
what is?
<rqou>
KMS
<whitequark>
hm, really?
<rqou>
that's what several of the random slide decks said
<rqou>
although maybe FBDEV can do some modesetting logic too, idk
<whitequark>
well it definitely does
* whitequark
wrote an fbdev driver once
<rqou>
the only FBDEV-based device i've used was the nintendo ds port of uclinux circa 2008
<rqou>
which cannot do modesetting
<rqou>
because the screen is always <X> by <Y> pixels, and the framebuffers are always at addresses <foo> and <bar>
<rqou>
there is a page flipping control register
<rqou>
(ok, there's actually a much more powerful 2d tile-based engine that wasn't exposed to linux)
<rqou>
so next stupid question: with DRM+KMS, why does X still need a driver tied to the GPU model?
<rqou>
that breaks your system occasionally
<whitequark>
no idea
<rqou>
wait, is "atomic mode setting" supposed to enable the amazing feature of "not flickering all my screen for five seconds every time a connector is (un)plugged?"
<rqou>
wow, what an achievement /s
<rqou>
(to be fair even windows can't reliably do that)
<rqou>
cyrozap: so far i haven't found a really good explanation of how opengl fits in this whole picture
<rqou>
e.g. "when I call glBegin, what happens?"
<whitequark>
rqou: opengl context is fetched from a TLS slot hardcoded to a specific position in glibc because otherwise games are too slow...
<rqou>
that's kinda ugly, but workable
<whitequark>
... then you proceed mutating global state until the library decides that it had enough, serializes what you want into a command buffer and sends it to a device, uploading shit like textures along
<rqou>
and this part involves DRM, or no?
<whitequark>
in my understanding DRM is exactly how the library can fill and send these buffers
<rqou>
unless you're nvidia and using the magic nvidia.ko? :P
<rqou>
anyways, so all gl rendering is controlled by the program that wants to 3d and doesn't involve tunneling through X?
<cyrozap>
rqou: "why does X still need a driver tied to the GPU model?" Actually, on some systems you can use xf86-generic-modesetting now.
<rqou>
when rendering 3d and the program created its desired pixels, how does this set of desired pixels eventually end up on the screen?
<whitequark>
rqou: usually, yes, that's direct rendering
<whitequark>
you can also have indirect rendering, when libgl serializes everything and sends it over network
<whitequark>
(when rendering 3d) now you are stepping outside GL
<whitequark>
there's wgl, glx, egl, and nsopengl, depending on your OS
<whitequark>
but basically they all provide a way to define a rendering target somewhere on screen, usually based on a platform window
<rqou>
ah so that's what all that random crap is :P
<whitequark>
yup
<rqou>
and back when spinning desktop workspace cubes were popular (compiz), how was that implemented?
<whitequark>
egl is the least insane of them all and standardized
<whitequark>
oh, that's a compositor
<rqou>
which does some magic with the wgl/glx/egl stuff?
<whitequark>
basically instead of glx giving out a rendering target bound to the screen, glx would give out an offscreen rendering target
<whitequark>
and the compositor then would use it as a texture
<whitequark>
btw, it's not gone with spinning cubes
<whitequark>
all DEs work like that by default on all OSes
<rqou>
and the compositor gets access to that offscreen target how?
<rqou>
magic dance through X?
<whitequark>
and in fact on wayland that's the *only* way
<whitequark>
gets access through X, yes
<rqou>
i know modern desktops have compositors, but the specific showing-off-demo of the spinning cube seems to no longer be in favor :P
<whitequark>
wow, keycode handling is a clusterfuck
<whitequark>
there's hid keycodes, which are translated into kernel keycodes, which are translated into not-so-kernel keycodes, which are translated into x keycodes, which are translated through a gtk keymap into gtk keyvals
<rqou>
the thing that maps shit from your keyboard into something meaningful?
<whitequark>
and half of that is done through completely fixed maps
<rqou>
yeah, my keyboard has a number of keys that cannot be used unless you <mumble mumble screw around with shit> because it sends a keycode that exceeded some limit in some layer somewhere
<whitequark>
>Linux kernel does not send keycodes > 255 to X. That is kernel limitation.
<rqou>
yeah that's probably it
<rqou>
i have a logitech k350 and some of the keys like the "photos" button don't work :P
<rqou>
the "Microsoft Word" button also doesn't work :P
<rqou>
so random question: at some time vaguely between 2012 and now, the linux console (no X) changed from "giant characters at VGA/SVGA/whatever resolution" to "tiny characters at (some approximate function of) native resolution." Is this related to KMS?
<whitequark>
yes
<whitequark>
well
<whitequark>
it's done by fbdev subsystem
<rqou>
ah ok
<rqou>
at least in my experience this transition didn't break anything
<rqou>
so before, was it using the actual VGA/SVGA text legacy functionality of the graphics card?
<whitequark>
yes
<rqou>
wtf
<whitequark>
why not?
<whitequark>
it's there, and it's configured by the bootloader / firmware
<rqou>
so switching VTs had to spend ages poking the GPU in and out of legacy mode?
<whitequark>
oh yeah
<whitequark>
in fact if you used xen with nvidia pci passthrough
<whitequark>
then you had to actually copy the VBIOS to the guest, because it can't be normally read
<whitequark>
so that the guest can set up a V86 VM (or just simulate 8086 code somewhere in x and/or kernel)
<whitequark>
why do you seem to dislike this state of affairs? it is very in line with your approach to build systems :p
<rqou>
because i actually have a personal interest in various graphics/desktop stuff to be working, and i don't have nearly as much interest in having build systems be working
<rqou>
:P
<rqou>
also, the build systems usually work just fine on my machine :P :P
<rqou>
whereas the graphics stuff doesn't
Hootch has quit [Ping timeout: 260 seconds]
Hootch has joined ##openfpga
pie_ has joined ##openfpga
cosmobird has joined ##openfpga
digshadow has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
pie_ has quit [Quit: Leaving]
cosmobird has quit [Remote host closed the connection]
pie_ has joined ##openfpga
cosmobird has joined ##openfpga
amclain has quit [Quit: Leaving]
cosmobird has quit [Read error: Connection reset by peer]
digshadow has quit [Quit: Leaving.]
digshadow1 has joined ##openfpga
m_w has quit [Quit: leaving]
cosmobird has joined ##openfpga
<nats`>
uhhhmmm shit somebody read chineese here ?
<whitequark>
you don't even ened chinese to know that
<jn__>
does the captcha use latin or chinese characters?
<rqou>
job title (choices are please select, student, engineer, project manager, department/branch?? manager, director, CEO)
<rqou>
industry segment (choices are <too much effort> :P )
<rqou>
company name
Bike has quit [Quit: leaving]
<rqou>
mailing address
<rqou>
and current location
<rqou>
huh the industry segment choices are pretty interesting
<rqou>
choices are: please select, communication systems, industrial controls and automation, automotive electronics, medical electronics, computer and related equipment, ...
<whitequark>
thats fairly standard no?
<rqou>
sorry, my internet connection briefly dropped
<rqou>
anyways, continuing on the list of industry segments:
<rqou>
consumer electronics, test and measurement, digital IC design, analog IC design, IC manufacturing, aviation/aerospace/marine, ...
<rqou>
research institution or <some form of higher education, not familiar with how it works>, office equipment???, "component agent" (not sure what this is), ...
<rqou>
military, lighting (e.g. LED lights), and smart grid
<rqou>
so many of these are standard but some of these are oddly specific
<whitequark>
rqou: purchasing agent, probably
<rqou>
yeah that makes sense
<rqou>
so the easy options are "学生" for the first dropdown and "科研院所大专院校" for the second dropdown
<rqou>
(these are "student" and "research institution")
<rqou>
hrm, my cable modem seems to be crapping out
<rqou>
wow, comcast is either really bad at networks or one of the neighbors bought some piece of crap from china
<egg|zzz|egg>
rqou: how's the vhdl parsing going?
<rqou>
i'm currently at the not-very-psychologically-rewarding step of implementing various "declarative items" :P
<rqou>
they're all mutually recursive with each other, so you never manage to get the feeling of "yeah, finished one!"
<rqou>
there isn't any grammar ambiguity as far as i can see here
<rqou>
the only major potential gotcha that i have been putting off is association_list
<rqou>
great, first comcast is crapping out and now the json formatter service i'm using is broken
<rqou>
welcome to cloud
<clifford>
rqou, re arachne-pnr-win64: is it a build issue or does arachne-pnr produce incorrect restults or crash? can you open an issue on github and include "@cliffordwolf" in the text?
<rqou>
it's a build issue caused by how i hacked up the build system
<rqou>
i haven't gotten around to cleaning this up
<rqou>
basically the build system runs "sed" on the Makefile to apply some ugly horrible hacks
<rqou>
and adding 384 broke the sed commands
<rqou>
fixing this is on the todo list
<rqou>
egg|zzz|egg: pretty sure this is the last hurdle: a subtype_indication in the actual_part of an association_list for a generic map
<egg|zzz|egg>
rqou: hmm
<rqou>
i have some conflicts and i don't understand why
<rqou>
they don't seem to actually break in GLR mode
<rqou>
hrm, i believe the problem is just that my grammar requires too much lookahead
<rqou>
egg|zzz|egg: nope, whee i actually broke it
<egg|zzz|egg>
rqou: huh
<rqou>
process procedure aaa is new bbb generic map(foo => bar(baz(0 to 2), qux(1 to 3))); begin end process;
<egg|zzz|egg>
rqou: wtf does process procedure mean
<rqou>
pretend this whole thing is supposed to be interpreted as a process statement
<egg|zzz|egg>
(process is not a reserved word in Ada)
<rqou>
ah ok
<rqou>
the process part isn't really relevant
<egg|zzz|egg>
ok
<egg|zzz|egg>
so then you just instantiate a generic procedure?
<rqou>
the relevant part is
<rqou>
procedure aaa is new bbb generic map(foo => bar(baz(0 to 2), qux(1 to 3)));
<rqou>
as a declarative item
<rqou>
instantiating a generic procedure named aaa from bbb
<egg|zzz|egg>
uh, that looks like a weird syntax for generic instantiation
<rqou>
where foo is a generic type
<rqou>
maybe vhdl is different
<egg|zzz|egg>
in Ada you don't use generic for the instantiation, and map isn't a keyword :-p
<rqou>
let's just say that i'm pretty sure that part is right
<rqou>
just focus on the foo => bar(baz(0 to 2), qux(1 to 3)) part
<rqou>
suppose foo is a generic type and the stuff on the right is a subtype_indication
<rqou>
(which might also look different in VHDL)
<egg|zzz|egg>
rqou: you do, e.g., procedure Deallocate is new Ada.Unchecked_Deallocation(Object => T, Name => Access_T);
<rqou>
wow, so VHDL added even more typing :P
<egg|zzz|egg>
yeah, it's a bit inconvenient to have to do it explicitly all the time in Ada already
<egg|zzz|egg>
but then they were among the first to have generics, and they did it reasonably usably, so eh
<egg|zzz|egg>
(bear in mind the landscape of languages from 83, the competition is C :-p)
<rqou>
i'm pretty legitimately stumped how to fix this
<rqou>
hrm
<rqou>
that's interesting
<rqou>
due to <mumble mumble reasons mumble mumble> it turns out that as long as there is no "juxtaposition of 'thingies' (it makes sense in my head, i swear!)" everything that's a subtype indication can parse as a name
<rqou>
including array constraints with (open)
<rqou>
because open is (afaik) a legitimate argument to pass to a function call
<rqou>
hrm, i'm going to sleep for now and think about it later
<rqou>
hopefully this is the last major hurdle
flaviusb has quit [Quit: Leaving.]
jeandet has joined ##openfpga
promach has quit [Ping timeout: 258 seconds]
promach has joined ##openfpga
jeandet has quit [Remote host closed the connection]
jeandet has joined ##openfpga
promach has quit [Ping timeout: 258 seconds]
scrts has quit [Ping timeout: 256 seconds]
scrts has joined ##openfpga
promach has joined ##openfpga
flaviusb has joined ##openfpga
promach has quit [Ping timeout: 256 seconds]
promach has joined ##openfpga
digshadow1 has quit [Quit: Leaving.]
amclain has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
azonenberg_work has joined ##openfpga
oeuf has joined ##openfpga
promach has quit [Ping timeout: 258 seconds]
egg|zzz|egg has quit [Ping timeout: 246 seconds]
Bike has joined ##openfpga
digshadow has joined ##openfpga
<whitequark>
rqou: just got some spam from @126.com advertising some sort of machine that ends with the paragraph "Join us! You worth to shot!"
jeandet has quit [Remote host closed the connection]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
Hootch has quit [Quit: Leaving]
pie_ has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
cosmobird has quit [Ping timeout: 258 seconds]
<cyrozap>
rqou: "it doesn't accept + in email addresses" You know there are disposable email services, right?
<rqou>
yeah, but too much work for a pdf that i don't directly need :P