tarceri__ has quit [Remote host closed the connection]
tarceri__ has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
agd5f has quit [Remote host closed the connection]
agd5f has joined #dri-devel
Daaanct12 has quit [Remote host closed the connection]
Daaanct12 has joined #dri-devel
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #dri-devel
slattann has quit []
nirmoy has joined #dri-devel
hch12907_ has joined #dri-devel
hch12907 has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
gpoo has joined #dri-devel
Daaanct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
i-garrison has quit []
Bennett has joined #dri-devel
slattann has joined #dri-devel
jcline has joined #dri-devel
jcline_ has quit [Ping timeout: 480 seconds]
<karolherbst>
dcbaker: do we have a solution for bindgen in meson now? I am still having problems with those stupid CL header files requiring external declared types and stuff...
<karolherbst>
ahhh
<karolherbst>
using configure_file mhh
slattann has quit []
pendingchaos has quit [Ping timeout: 480 seconds]
thaytan has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
thaytan has joined #dri-devel
<dcbaker>
karolherbst: yes, the rust module has a bindgen function
<karolherbst>
dcbaker: yeah, already using that, but I think I _requre_ support for mixed gen+static files
<karolherbst>
*require
<karolherbst>
I don't see how I could solve my problem without that
<karolherbst>
or env var support for include!
mattrope has joined #dri-devel
<karolherbst>
I am able to generate mesa bindings without issues, but OpenCL ones are..... annoying
i-garrison has joined #dri-devel
<emersion>
is the DRI interface mostly mesa-internal, or is it used by third-party software as well?
<emersion>
i know minigbm uses it, but are there more users?
<karolherbst>
emersion: well, it's an X extension, isn't it?
<emersion>
hm, i'm talking about the mesa dynamic lib thing
<karolherbst>
you mean libgbm.so then?
<emersion>
include/GL/internal/dri_interface.h
<karolherbst>
ahh
<emersion>
well
<emersion>
now i notice it's in a dir called "internal"
<emersion>
:P
<karolherbst>
:D
<karolherbst>
yeah.. all that loader stuff is a little....
<emersion>
maybe the death of classic drivers could allow us to clean that up a little
<karolherbst>
maybe
<karolherbst>
but gallium also uses it
<emersion>
yeah, i mean remove one layer of abstraction
<karolherbst>
yeah
<karolherbst>
probably
<bnieuwenhuizen>
emersion: I think glamor also uses it directly?
<emersion>
glamor is an internal user
<emersion>
just like GBM
<emersion>
hmm
<bnieuwenhuizen>
well, separate repo, so internal is in the eye of the bholder :P
<emersion>
eh, maybe not
<emersion>
i though i saw some glamor stuff in mesa, but no
nchery has joined #dri-devel
lynxeye has quit []
tarceri__ has quit [Remote host closed the connection]
tarceri__ has joined #dri-devel
sdutt has joined #dri-devel
slattann has joined #dri-devel
<dcbaker>
karolherbst: i have a branch that allows mixing generated sources, but i got some pretty big design changes requests, so i haven't gotten back to it yet
slattann has quit []
lemonzest has quit [Quit: Quitting]
frieder has quit [Remote host closed the connection]
thellstrom has quit [Ping timeout: 480 seconds]
hansg has quit [Remote host closed the connection]
xexaxo_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
gouchi has joined #dri-devel
craftyguy has quit [Remote host closed the connection]
sdutt has quit []
sdutt has joined #dri-devel
<emersion>
bnieuwenhuizen: it seems like it's not used by Xorg anymore
<emersion>
but it's pretty new
<emersion>
hm, can't find the commit
<emersion>
but daniel said "until relatively recently"
<daniels>
I try to purge the finer points of GLX/DRI from my brain …
<emersion>
:D
<emersion>
well, this means we can probably completely get rid of that dri interface at some point
<daniels>
yeah, it should be able to get flattened when classic gets removed
<pinchartl>
airlied: you mentioned "Xilinx even submitted a drm driver in the past" in reply to the lwn article on not-a-gpu. are you referring to the upstream zynqmp-dpsub driver, or something else ?
<emersion>
nice
robmur01 has quit [Read error: Connection reset by peer]
<agd5f>
pinchartl, IIRC it was for the XRT devices
<pinchartl>
thanks
robmur01 has joined #dri-devel
<mareko>
dri_interface.h doesn't have anything to do with classic, it's an interface for libGL and libEGL, though I guess we could put drivers, libGL, and libEGL into the same lib hardlinked as libGL and libEGL to eliminate dri_interface.h
<agd5f>
pinchartl, subject: Xilinx AI engine kernel driver
craftyguy has joined #dri-devel
<emersion>
agd5f: or just make stuff use a gallium-tailored API instead of dri_interface.h
<emersion>
err
<emersion>
mareko: ^
iive has joined #dri-devel
<emersion>
and make sure the interface is not versionned apart from "driver version matches exactly libGL/libEGL/libgbm version"
<emersion>
so that we don't have such historical baggage
dv_ has quit [Ping timeout: 480 seconds]
X-Scale has joined #dri-devel
thellstrom has joined #dri-devel
dv_ has joined #dri-devel
muhomor has quit [Remote host closed the connection]
sravn_ has joined #dri-devel
sagar_ has joined #dri-devel
sravn has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
jkrzyszt has joined #dri-devel
jkrzyszt has quit []
jkrzyszt has joined #dri-devel
rasterman has joined #dri-devel
bcarvalho has quit [Remote host closed the connection]
bcarvalho has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
xexaxo_ has joined #dri-devel
<zmike>
we having pubkey issues on gitlab again?
xexaxo_ has quit [Ping timeout: 480 seconds]
<alyssa>
danvet: twitter isn't really the medium for long form discussion of r/e'd hardware so uh
<alyssa>
"plane updates is still done directly and under full control of the driver"
<alyssa>
define directly and full control?
<alyssa>
each dcp is modeled as a single CRTC with planes/framebuffer
<danvet>
ah I guess I got that wrong and though crtc is just the modeset side
<alyssa>
and every frame the kernel serializes the entire state of the CRTC, all planes, their corresponding framebuffers into a monster object and passes that ot the firmware as the "swap" command
<danvet>
forgot where atomic_flush is ...
<alyssa>
CPU overhead of the above scheme is probably unneccessarily high but it only runs 60 times a second on an M1 core, it's fine ;-p
<danvet>
yeah I guess with that the trick is only in how you get the correct timestamp out for this (some people really care)
<danvet>
and whether atomic test_only works
<danvet>
no one cares about kms cpu overhead, doesn't run often enough
<alyssa>
haven't looked at what timestamps and test_only are in the api?
<danvet>
the crtc->event you need to send out to not hang stuff
<danvet>
comes with a timestampe
<alyssa>
yeah, ok, I am used to 3D userland where you really care because of dumb benchmarks with millions of draws/second
<alyssa>
right..
<danvet>
it should match as close as possible to top-of-frame
<alyssa>
Currently I have that tied to the "swap complete" callback
<alyssa>
not sure where in the frame that fires exactly so it might be off by a constant bias.
<danvet>
I guess when you figure out how vblank irq happens you should be able to be a notch more precise
<danvet>
ideally it's a hw timestamp
<alyssa>
I don't believe we get any IRQs except for the physical layer of the mailbox
<danvet>
the atomic test-only stuff is all the atomic_check callbacks
<alyssa>
It's all IPC
<alyssa>
atomic test only, I assume, is implemented entirely in the kernel without touching the DCP at all
<danvet>
uh, then hopefully it's a timestampe somewhere
<alyssa>
Oh, I wonder if one of the arguments of swap complete has the timestamp..
<danvet>
it's probably in a funny clock, but if it increments in regular intervals
<alyssa>
nod
<alyssa>
let me check a trace
<alyssa>
of course the argument struct is 1.5kb and filled with uninitialized data 🤦♂️
<alyssa>
mark of quality here
<danvet>
solid engineering
<danvet>
some vblank message would also be good so you can advertise vblank support without doing fake swaps (which I think would always race in some stupid way)
xexaxo_ has joined #dri-devel
<danvet>
I don't think userspace can do good use of the timestamp without vblank support
<danvet>
for atomic_check the nasty stuff is bw/clock limits in multi-plane configs
<danvet>
but also not sure how to r/e that :-(
<alyssa>
hum. not sure what limits we have there indeed.
<alyssa>
okay, the word at offset 0x20 of the swap complete callback increments monotonically
<alyssa>
the first few swaps it increments by a lot (dcp busy, missing frames due to modeset, something like that maybe?)
<alyssa>
but once it settles down it incrementally by a constant 1562 or 1563
<alyssa>
could easily be a timestamp in a funny unit
<Lyude>
this sounds a lot like how nvidia does modesetting
<Lyude>
e.g. communicating all display state over to some magic firmware that does all of the things for you
jewins has joined #dri-devel
<alyssa>
Lyude: do all the uber proprietary vendors talk to each other secretly? :-p
<Lyude>
hehe, I wouldn't be surprised if someone from nvidia got hired by apple to work on display stuff
<ccr>
a secret cabal of GPU illuminati
<Lyude>
like i've seen stuff on old matrox gpus that seemed eerily similar to old nvidia GPUs a couple of times
<danvet>
there's also not really that many ways to do this
<danvet>
the funniest part was when amd pulled in a lot more of their display
<danvet>
and they were all "our hw is super special"
<Lyude>
Lol
<alyssa>
"special"
<Lyude>
any pizza is a party pizza if you believe in yourself
<danvet>
compared to all the soc fun we've had it was very vanilla
<urja>
:D
<danvet>
hm reminds me, I need to put pizza ingredients on my grocery list
xexaxo_ has quit [Ping timeout: 480 seconds]
<alyssa>
danvet: don't forget vanilla extract
<danvet>
for ... pizza?
<imirkin>
danvet: isn't it just a single ingredient ... "frozen pizza"? :)
<danvet>
I haven't done that since about 20 years or so
<danvet>
pizza here comes on a proper baking stone and fresh dough
<karolherbst>
dcbaker: yeah... although I am wondering if support env vars might be the better solution here :/ copying files around is annoying
muhomor has joined #dri-devel
<dcbaker>
It is, but we're kinda caught in a hard place here. rustc doesn't seem intrested in a command line argument, none of our backends support env variables and Jussi is really unhappy with the idea of wrapping the compiler
<dcbaker>
the copying would all be user transparent in my series, but I used a dictionary and people didn't like that, they want a function
<dcbaker>
s/function/named function/
ngcortes has joined #dri-devel
<Lyude>
hm
<Lyude>
curious - I'm guessing this work y'all are talking about is preparing mesa for rust?
idr has joined #dri-devel
<dcbaker>
karolherbst: but I do have to figure it out for crate support. I might just have to push *really* hard on the wrapping :/
<dcbaker>
Lyude: yeah
<karolherbst>
dcbaker: ohh still no crate support?
<karolherbst>
Lyude: yep :)
<dcbaker>
I got my series working, and then got to the "clean this up and make it mergable" and got sidetracked
<Lyude>
nice! I am quite excited for rust :)
<karolherbst>
Lyude: wait a second :D
<karolherbst>
ehhh
<karolherbst>
why is it broken..
<Lyude>
?
<karolherbst>
"Number of devices 0" :)
<karolherbst>
:(
<karolherbst>
ohh wait
<alyssa>
dcbaker: inb4 flamewars
mlankhorst has quit [Ping timeout: 480 seconds]
<dcbaker>
lol
<dcbaker>
Ususally I mention rust and the immediately run
<karolherbst>
oh no
<karolherbst>
the pipe loader stuff doesn't work
<dcbaker>
but right now I'm in a flame war about whether type annotations in python are useful
mlankhorst has joined #dri-devel
<imirkin>
dcbaker: and you'd be on both sides of that war? :)
<dcbaker>
No, I'm firmly on the side that type annotations are invaluable
<dcbaker>
I don't write python without them anymore
<karolherbst>
heh...
<dcbaker>
they catch so many cornercase bugs
<karolherbst>
why is it using the dynamic pipe loader
<imirkin>
i remember there was some sort of typechecking thing in the py2 days. it was very clever, but ultimately not very good
<alyssa>
dcbaker: I am really scared to take an "into to software design" class this fall (uni requirement)
<alyssa>
I previewed the slides, "What the benefits/drawbacks of static vs dynamic typing?"
<Lyude>
imirkin: it's gotten better but it's probably not what you are expecting
<alyssa>
how do I not answer this as "dynamic typing is good if you're lazy and like writing broken code"
<imirkin>
Lyude: the "clever" thing would like execute some of the code somehow to determine which types were being used. or something. i forget.
<urja>
"lazy and like writing broken code" it me
<dcbaker>
Given that pretty much every dynamically typed langauge that isn't morabound is adding type checking, I think the answer is "type checking good"
<Lyude>
dynamic typing is good for small applications with little surface for errors imho. that's, really about it. unfortunately i still don't use type annotations in my python code though lol
<dcbaker>
I think a lot of it is that functional languages proved that good, reliable type inference is possible
<Lyude>
that as well. rust proved to me a lot of things including that types can actually rule and you can expand on them without creating java
<alyssa>
Lyude: this class will be teaching how to write enterprise-scale code in Java
<dcbaker>
I cringe when I see things like `static SomeReallyLongTypeName<SomeOtherReallyLongTypeName> = SomeREallyLongTypeName(SomeOtherREallyLongTypeName()`
<alyssa>
helpmehelpmehelpmehelpmehelpmehelpme
<Lyude>
alyssa: oh lord, yeah I feel that I've done classes like that before ._.
<alyssa>
Help I'm stuck in an ObjectOrientedObjectFactory
<imirkin>
alyssa: types are complicated. like e.g. expressing an identity function's type. i dunno what the focus of that class is, but don't necessarily poo-poo the whole idea until you're really familiar with all the ideas
<jenatali>
Types like that are why I'm a big fan of auto in C++
xexaxo_ has joined #dri-devel
<jenatali>
When appropriate of course, sometimes it just obfuscates stuff for no reason
<imirkin>
jenatali: if only people used hungarian notation in order to generate shorter names :)
<imirkin>
jenatali: not to mention require explaining to people wtf a "long pointer" is vs a plain pointer
<jenatali>
Ugh
<alyssa>
Lyude: insert kernel vs apps hundarian here
<alyssa>
hungarian
<Lyude>
alyssa: my college thought int_foo (or foo_int, I forget the order) was hungarian notation
<jenatali>
Most of D3D's code does use p prefixes for pointers, but that's about it these days
<karolherbst>
jenatali: rust has auto more or less as well kind of :p
<Lyude>
p makes sense though
<Lyude>
like thing_foo and pthing_foo
<dcbaker>
rust has proper type inference because of it's functional influence :)
<imirkin>
alyssa: well, that class is probably not going to touch on the interesting points about types. but they do exist :)
<Lyude>
i hate to say it but rust has firmly made me never want to be near c++ lol
<jenatali>
karolherbst: Yeah, Rust with a proper IDE that automatically inserts type annotations while you're reading the code, that's really nice
<dcbaker>
Lyude: If you can use C++14 or later it's not bad, even after doing Rust
<Lyude>
ahh
<dcbaker>
but if you have to deal with crufty c++, ugh
<Lyude>
yeah I haven't used C++ in ages
<alyssa>
dcbaker: I'm at the point where I am comfy with C so if I am going to use anything else it has to be a lot better than C, not just a little
<imirkin>
alyssa: e.g. i liked a class back in the day called something along the lines of "programming languages".
<Kayden>
hehe, p_* is either a pointer or pipe_* :)
<alyssa>
dcbaker: Rust is one of the few langs that I find a lot better than C
<alyssa>
C++ very much is not
<Lyude>
i'm pretty much all C, python, bash, and rust these days
<Kayden>
I've started using v_foo for void * arguments that get turned into actual type * foo immediately after
<dcbaker>
alyssa: Yeah, C always feels like "I'm driving a rust car full of spears at 180 mph down a bumpy road with no breaks and no steering wheel
<dcbaker>
anything is better than C
<urja>
*snort
<karolherbst>
dcbaker: even C++ :p
<karolherbst>
even COBOL :O
<Kayden>
clearly not /anything/, heheh
<Lyude>
COBOL should be illegal
<karolherbst>
Lyude: be lucky you never saw COBOL code in the wild
<imirkin>
a computer without cobol and fortran ... is like a piece of chocolate cake, without ketchup and mustard
<Lyude>
karolherbst: oh yeah, I imagine. when I was in school I was basically deadset on avoiding jobs like that and somehow managed to get lucky enough to
<dcbaker>
karolherbst: yes, becausee I can't write COBOL, so I wouldn't :D
<karolherbst>
dcbaker: be lucky
<karolherbst>
those parts of the brain I never get back
<dcbaker>
karolherbst: I leaned to program in QBasic, so…
xexaxo_ has quit [Ping timeout: 480 seconds]
<karolherbst>
I actually looked at worse
<karolherbst>
there is this OpenCOBOL converting COBOL into.. well.. C
<karolherbst>
it uses memset and memcpy 90% of the time :)
<dcbaker>
I've heard of that, though it's GNUCOBOL now, right?
<karolherbst>
could be
<karolherbst>
seems like my OpenCL impl in rust uses the dynamic pipe loader.... I should change that
<emersion>
i kind of get why writing a gfx driver in C is painful but… rust is just too complicated
<emersion>
anybody has considered something else, like e.g. zig?
<Lyude>
tbh, rust was complicated for me to learn but one of my favorite things about it is the fact there's not a whole ton to learn
<Lyude>
a lot of it isn't as painful as it seems, it just requires thinking about how you write things a lot differently
<emersion>
compared to C++?
<emersion>
well, the rust API surface is quite huge
eletrotupi has joined #dri-devel
<emersion>
also an issue is that anything that doesn't exactly fit the rust model will be immensely painful
<Lyude>
emersion: I mean, I haven't used C++. and i'm mostly just talking about stuff like stdlib and the language itself, which honestly didn't seem that big to me
<karolherbst>
Lyude: you mean, how you write non buggy C code :p
<Lyude>
emersion: there's actually some work on improving some stuff like that, for instance providing a way to have shared mutability without runtime costs
<karolherbst>
you need some kind of synchronization, don't you?
<karolherbst>
ahh
<Lyude>
yeah this isn't for multi-threading
<Lyude>
I guess my take on rust is it seems like everything that's painful right now is being worked on, and unlike something like C I could actually join in and suggest new features that would help make things less painful. I can't imagine being able to do that nearly as easily with something like C/C++
<emersion>
C is almost frozen and that's a good thing
<karolherbst>
Lyude: no plan on joining the ISO C meetings? :p
<dcbaker>
emersion: zig is still moving too fast to use for anything real I think
<emersion>
my idiomatic C code written today will stay idiomatic in 20 years
<karolherbst>
emersion: I hope it won't
<emersion>
dcbaker: hm, makes sense. it's true that it's quite young
<Lyude>
emersion: I mean - rust has these same guarantees, things aren't stabalized until they're basically frozen
<karolherbst>
today people don't even think using bool is idiomatic
<emersion>
Lyude: yeah but code you write today will become outdated quite quickly
<dcbaker>
emersion: we tried to write meson support for it, and it was just too hard to support multiple versions, there's not preprocessor and even simple things like "what is the name of this stdlib method" changed three times in three versions
<emersion>
i see
<emersion>
hopefully it'll stabilize a bit quicker than rust
<dcbaker>
I think zig will find a niche, but I actually think it'll probably be for firmware, since most of their guarantees seem to be around memory allocation rather than safety. But I also thought Rust was going to end up being a niche thing, so… take my opinions with a grain of salt
<emersion>
i personally think languages like zig would be a pretty good fit for mesa
<Lyude>
emersion: yeah but that's true with many a thing, and as long as the code still builds and compiles I don't think it's that bad.
gouchi has quit [Remote host closed the connection]
<emersion>
Lyude: it's always extra maintenance, be it only reviewing patches that align to The New Style Of The Year
* emersion
also always annoyed by things like dependabot
<karolherbst>
emersion: you can also allow any version and deal with compilation bugs :)
<emersion>
compilation bugs are unlikely for properly maintained libraries
<karolherbst>
but there is a simple solution to this dependency mess: just write perfect APIs from the start ¯\_(ツ)_/¯
<karolherbst>
emersion: you must hate LLVM then
nirmoy has quit []
slattann has quit []
Duke`` has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
muhomor has quit [Remote host closed the connection]
muhomor has joined #dri-devel
illwieckz has quit [Remote host closed the connection]
illwieckz has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
<jekstrand>
zmike: Did you run CTS and piglit on that there ANV MR for pimitive lists?