<daniels>
jenatali: CCed a couple of relevant people
<jenatali>
daniels: Thanks!
<daniels>
np :)
camus1 has joined #dri-devel
<daniels>
jenatali: I need to have a word about 'modifier == 1' however :P
<jenatali>
daniels: Yeah I expected that needed changes. That was the easiest / least invasive thing I could do, but I'm okay with coming up with a different solution there now that I can actually talk to people about this whole thing
<daniels>
jenatali: if you can braindump about where that comes from and why, I'll try to go through it tomorrow
<jenatali>
daniels: I'll post it in the MR and tag you
<daniels>
A+
camus has quit [Read error: Connection reset by peer]
The_Company has quit []
Company has joined #dri-devel
iive has quit []
fxkamd has quit []
tursulin has quit [Read error: Connection reset by peer]
Haaninjo has quit [Quit: Ex-Chat]
ybogdano has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
karolherbst_ has quit [Ping timeout: 480 seconds]
karolherbst has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
adjtm has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Akari` has joined #dri-devel
Akari has quit [Read error: Connection reset by peer]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<alyssa>
Kayden: etc: Any advice on bringing up new hardware with GenXML driver?
<alyssa>
I get the sense this will work on the first try... if I ever can get the driver to build! ;-)
aravind has joined #dri-devel
<alyssa>
I guess #ifdef'ing out whatever errors as a first pass isn't so bad
X-Scale has joined #dri-devel
[X-Scale] has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
<anarsoul>
hey folks, how crazy is idea to emulate instancing in the driver?
<anarsoul>
I believe that lima can do it more efficiently at least for divisor = {0, 1} than doing it in app
Company has quit [Quit: Leaving]
<anarsoul>
well, in theory any divisor is OK if hw behaves correctly with stride = 0 :)
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #dri-devel
Duke`` has joined #dri-devel
Daanct12 has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
mattrope has quit [Read error: Connection reset by peer]
zrusin has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
aravind has quit [Read error: Connection reset by peer]
aravind has joined #dri-devel
zackr has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
zrusin has quit [Remote host closed the connection]
zrusin has joined #dri-devel
itoral_ has joined #dri-devel
reductum has quit [Quit: WeeChat 2.8]
itoral has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
<imirkin>
does anyone know if i should just be able to do like "dpkg -i glibc-from-unstable" on a debian stable box? or will it break everything? (i'm using the lava-rootfs to run tests, but my local builds are against glibc 2.33, so it complains)
sadlerap1 has joined #dri-devel
<imirkin>
(trying to just run the compiled binaries without chroot doesn't work either, due to at least a missing libwayland dep ... maybe i can just get that installed on the "main" system though...
sadlerap has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<airlied>
mripard: can you pick up or reply to joel stanley patch on dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
adjtm has quit [Quit: Leaving]
danvet has joined #dri-devel
camus has joined #dri-devel
pnowack has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<Kayden>
alyssa: that seems like a reasonable plan. having the overall function to upload all state be compiled per-gen is probably a good start, then you can replace bits with genxml functions as you go
jkrzyszt has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
rasterman has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
adjtm has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
pcercuei has joined #dri-devel
zackr has joined #dri-devel
zrusin has quit [Read error: Connection reset by peer]
rgallaispou1 has joined #dri-devel
<MrCooper>
emersion: presumably the [Mesa-dev] subject prefix broke DKIM signatures, so I've disabled that
<emersion>
oh i thought it was already disabled
<emersion>
good call
<emersion>
maybe i assumed it wasn't because dri-devel didn't have a subject prefix, only a footer
<MrCooper>
yeah, I was wondering what could be the issue, until I noticed the prefix :)
<emersion>
jenatali: ^ this should help with the spam issues
<MrCooper>
imirkin: most definitely not as simple as dpkg -i; you can try it with apt, but it'll likely pull in lots of stuff from sid at best
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
lanodan_ has quit []
lanodan has joined #dri-devel
<danvet>
javierm, generally wait 1-2 weeks for driver acks
<danvet>
but then if you have acks for all of them, just push
<danvet>
also maybe ping gregkh for an ack that this goes through drm
<danvet>
drivers/video/console is at the intersection between gfx and vt stuff
<danvet>
so good to coordinate just in case
<javierm>
danvet: Ok, thanks for the info
<danvet>
javierm, to clarify: once you waited 1-2 weeks and have acks on all patches, you can push
<danvet>
even if you don't have a driver maintainer ack from everyone
<danvet>
we wouldn't be able to get any refactoring done otherwise
adjtm is now known as Guest6288
<danvet>
and "make refactorings easier" was pretty much why drm-misc was started
adjtm has joined #dri-devel
<javierm>
danvet: got it
<javierm>
danvet: I've contributed to different subsystems in the past but drm is really a breath of fresh air :)
gawin has joined #dri-devel
Guest6288 has quit [Ping timeout: 480 seconds]
<doras>
<MrCooper> "doras: AFAICT libgbm.so.1 is..." <- MrCooper: libgbm in org.freedesktop.Platform mostly serves as a frozen API/ABI for the GBM frontend (gbm.h). The Mesa extension (.GL.default) comes with its own copy of libgbm which gets loaded first when it is present. The idea of shipping two versions is to allow Mesa to use newer libgbm which is not limited to the frozen GBM frontend API/ABI.
<danvet>
javierm, largely I just want to not do stuff, so I offload everything
<danvet>
:-)
<MrCooper>
doras: right, and my point is as long as the former has support for loading external backends, the nvidia driver should be able to work with that, no need to move Mesa's backend to a separate file which needs to support multiple backend ABI versions as well
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<doras>
MrCooper: but since in reality we have the Mesa extension serving libgbm for the entire runtime in pretty much every scenario (the extension's lib directory is in /etc/ld.so.conf), so it is now expected to be able to load external GBM backends as well. This means we need to introduce a canonical path for all external GBM backends to live in, and it introduces this strange implicit cross-extension dependency that we otherwise never had.
<doras>
The fact that the GBM backend ABI version is actually runtime-negotiated kind of saves us here, but it relies upon Mesa not being naughty and breaking backwards compatibility in the core GBM ABI.
<doras>
In other words: libgbm must be able to load nvidia's GBM backend even if nvidia remains at ABI version 0 forever, while Mesa's backend continues to newer ABI versions.
OftenTimeConsuming has quit [Ping timeout: 480 seconds]
Daanct12 is now known as Danct12
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
<MrCooper>
doras: that's pretty much the point of having a versioned ABI :)
<doras>
If we start to have things like "you need Mesa version X at minimum to run the newer nvidia driver" or "you need nvidia version Y to use the newer Mesa version" because of this GBM backend introduction, things will start to get complicated and very much broken.
OftenTimeConsuming has joined #dri-devel
<doras>
If libgbm was a neutral entity living in its own world (and git repo) like other loaders, all of this might have been a bit easier to manage.
<MrCooper>
not sure it really would have; e.g. if it was in glvnd, a lot of the same issues would just apply to that instead of Mesa, plus then we'd have to maintain support for multiple ABI versions in Mesa's backend
<doras>
I agree that it complicates things.
<doras>
libgbm now has 3 ABI interfaces: frontend, backend and core. It feels like a standalone entity, yet it also has backdoor for Mesa. Not a very elegant architecture to have.
ppascher has quit [Remote host closed the connection]
<mripard>
airlied: done
Haaninjo has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
danvet has joined #dri-devel
imre is now known as Guest6291
imre has joined #dri-devel
Guest6291 has quit [Ping timeout: 480 seconds]
ppascher has joined #dri-devel
nchery has joined #dri-devel
mclasen has joined #dri-devel
<zmike>
eric_engestrom / dcbaker: can we get a 22.0 milestone?
aravind has quit [Ping timeout: 480 seconds]
itoral_ has quit [Remote host closed the connection]
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #dri-devel
Luc has joined #dri-devel
enunes has joined #dri-devel
vivijim has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
<hakzsam>
dj-death: jekstrand: does dEQP-VK.texture.filtering_anisotropy.single_level.anisotropy_*.mag_linear_min_linear pass on ANV? (it's part of vk-gl-cts master)
thellstrom1 has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
thellstrom has joined #dri-devel
thellstrom has quit []
thellstrom1 has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
mattrope has joined #dri-devel
<dj-death>
hakzsam: on my gen12 yes
<dj-death>
hakzsam: it's only 4 tests right?
<hakzsam>
yes
<hakzsam>
thanks
<dj-death>
ok, just checking, I may not have the latest CTS built
khfeng has quit [Ping timeout: 480 seconds]
<hakzsam>
you need a ~recent vk-gl-cts
<dj-death>
I'm using a vulkan-cts-1.2.8.0-rc3+++
<dj-death>
few more commits on top of that
<hakzsam>
if you have 5281a5852f80ad143f1e9839d8d4c89a3a4ee56e it's fine
sdutt has joined #dri-devel
tarceri has quit [Ping timeout: 480 seconds]
Luc has quit [Remote host closed the connection]
Company has joined #dri-devel
austriancoder_ has quit []
austriancoder has joined #dri-devel
kmn has quit [Ping timeout: 480 seconds]
rgallaispou1 has left #dri-devel [#dri-devel]
fxkamd has joined #dri-devel
apteryx_ has left #dri-devel [#dri-devel]
Duke`` has joined #dri-devel
iive has joined #dri-devel
<danvet>
emersion, where was that irc chat about boosting so I can catch up?
<emersion>
hm i linked it at some point in the thread…
dllud has quit [Read error: Connection reset by peer]
<jadahl>
so these boost things are about ramping up clocks before animations etc? using input methods doesn't seem like it necessarily should do that imo. typing in a terminal ramping up gpu clocks seems inefficient
<MrCooper>
yeah (ideal would be a working crystal ball or time machine :)
jkrzyszt has quit [Ping timeout: 480 seconds]
<jadahl>
what about the "kick the gpu" ioctl?
<vsyrjala>
what does that do that "submit work to the gpu" ioctl doesn't?
<emersion>
vsyrjala: apparently not soon enough for google…
<emersion>
they have 50ms lag or so for some reason
<emersion>
tbh i don't really understand why
<vsyrjala>
oh is this about that psr wakeup thing?
<emersion>
yeah
<vsyrjala>
and people are trying to put in gpu boosting there too for some reason?
<robclark>
50ms is exit-psr.. IME "booting up" the gpu from suspend takes ~1.5-2ms, but that is enough to miss a vblank.. esp if you don't have to wait for devfreq to realize you are busy (but drm/msm handles that part of things a bit differently)
<robclark>
I think we have at least three copies of roughly the same input handler downstream (one to boost cpu.. that one has a cooldown period so typing doesn't just constantly boost), and then others for psr and gpu boost
<vsyrjala>
for gpu wakeup can't you just submit a nop to it ahead of time while you're preparing the real work
<robclark>
not easily, due to how sandbox architecture works..
<robclark>
I mean, the alternative is we keep doing what we're doing downstream.. and generic linux can soldier on without nice things ;-)
<danvet>
yeah I think we need the boosting thing, but probably more like configurable of some sorts
<robclark>
maybe some sysfs to configure the input filter?
<danvet>
robclark, I think the "pass input fd to drm master fd" sounds pretty good
<danvet>
which was tossed around
<danvet>
to establish the link, doesn't ever need to happen afterwards
<danvet>
and the boost link would then also nicely switch with compositor switches and multi-seat and everything
<robclark>
maybe.. although I'm not sure the process that has sandbox access to drm device has input access
<danvet>
robclark, set that up before you get this all started then
<danvet>
except if you have some really funny sandboxing going on
<robclark>
yeah, that might work, I suppose.. not sure but at least if it isn't cleared implicitly it could maybe be done before chrome(ium) starts
<danvet>
robclark, I do get why the explicit ioctl on each even isn't great, because a) adds latency and b) might not be doable with sandbox
<emersion>
you can pass around the "boost" FD from the input process to the DRM process maybe?
<danvet>
hence establish link once at startup
yogesh_mohan has quit [Ping timeout: 480 seconds]
<danvet>
and that really should be doable somehow
<danvet>
and then once it's done, lock down the sandbox further
<robclark>
yeah, one-time setup is defn better than having to do it each time there is input
<danvet>
like somehow you need to get the drm fd into your sandbox too, before you lock down any further open() calls
<danvet>
robclark, btw while you're around, can you perhaps chime in on the virtio poll semantics
<danvet>
I'm not terribly enthusiastic about this uapi we just added
<MrCooper>
the DRM driver doesn't know if/when input results in GPU work, the display server might
<danvet>
MrCooper, yeah hence why display server should set up the link
<MrCooper>
rather display server should boost directly
<danvet>
and if it passes libinput eventfd or so, we should be able to get this pretty much as good as it ever gets
yogesh_mohan has joined #dri-devel
<danvet>
MrCooper, too late and might not be possible or something like that
<danvet>
or not without a few more ipc to get the boost signal to the sandboxed process which can actually do the ioctl
<robclark>
danvet: ok, I'll have to get caught up on that virtio thread, I guess
<MrCooper>
I mean any boosting mechanism should be for active use by the display server, not implicit based on input
<jadahl>
danvet: and any activity on an input fd will boost things up?
<jadahl>
e.g. for gnome-shell, the most complicated animations happens after a single key press
<robclark>
jadahl: there is a filter table configured which sort of input events (ie. keypress, mouse, touchscreen, etc)
<robclark>
but yeah, things like window switcher animation is something that downstream addition of input-boost helped
<jadahl>
so e.g. pressing the super key makes things go to max, but a-z does not?
<vsyrjala>
how does one tell it what to boost and by how much?
<jadahl>
why shouldn't the compositor just tell the kernel when it should ramp up explicitly?
<robclark>
just boost, and then let governor take over as things get into steady state
<danvet>
robclark, thx
<danvet>
jadahl, generally the clock boosting has a cooldown, to avoid abuse
<robclark>
we have metrics measuring power, latency, etc.. we haven't seen a power regression with this approach
<jadahl>
sounds a bit wierd to put compositor / shell behaivour into the kernels prediction mechanisms...
<jadahl>
when the compositor could just tell the kernel up front when it knows heavy things are coming
<robclark>
we do that all the time with dev and cpu freq governors
<jadahl>
they don't work well with gnome-shell really as of now
<jadahl>
we end up missing the first frame, then entering feedback loops of low cpu usage with half framerate. the only fix we can do is accept the initial stutter and paint anyway even after missing the flip deadline, hoping the scheduler ramped up, but that's not really good enough
tarceri has joined #dri-devel
<robclark>
I mean, cpufreq stuff somehow takes into account the latency of transitions between power states.. as far as how things work now with gnome-shell, I suppose on the gpu side you aren't testing with any drivers that use input boost, since that is all downstream ;-)
<robclark>
but avoiding that initial stutter is the whole point of this exercise ;-)
<jadahl>
yea, clearly not :) just saying, my gut feeling is that it's not the right approach, when all I want is a way to communicate compositor intent to the kernel :P
<jadahl>
instead of the kernel trying to guess
<jadahl>
anyhow, I have to go, I would love to talk more about this another day
* jadahl
disappears
<robclark>
IME boosting a bit more than you need to (ie. if a key is not triggering fullscreen animation) isn't really too bad as long as you avoid the spacebar-heater trap ;-)
<robclark>
on drm/msm side, the gpu boost is really just early-resume (and if the device is not suspended, then nothing to do).. we handle the freq boost when rendering is submitted if the gpu has been inactive for a (relatively) longer time, since freq transition is fast enough to delay until rendering is submitted
<alyssa>
robclark: what's the spacebar-heater "trap"?
<alyssa>
I need that feature in my kernels
<alyssa>
buggy power management gets me through the Canadian winter
<robclark>
for cpu-boost there is a cooldown period where we won't boost again.. so typing or holding down a key doesn't constantly boost
<HdkR>
Hold down space bar, forever boost, useful to keep warm in the cold of winter.
<robclark>
danvet: revert first, ask questions later, does not seem to be an unreasonable approach
<zmike>
dcbaker: nice, thanks!
<MrCooper>
there are trivial scenarios where implicit boosting based on input will boost for nothing, even a trivial display server based implementation where it boosts whenever input might at least in theory result in GPU work will consume less energy
<eric_engestrom>
dcbaker: thanks!
<MrCooper>
and boost in all the same cases where it actually helps
<dcbaker>
np!
pekkari has joined #dri-devel
* zmike
adds the first issue
<robclark>
MrCooper: I suppose an input event which *only* moves the cursor would be an example.. although in practice there are usually other things that react to cursor position change. And in the PSR case you'd still want to early-exit PSR for mouse cursor movement
<MrCooper>
there's also keyboard input while nothing has focus
<robclark>
yeah.. I suppose.. but I guess enough of a corner case to not worry too much about
<robclark>
we do keep a close eye on power consumption / battery life
<MrCooper>
seems like you're hell-bent on the downstream solution and not very interested in alternatives
<robclark>
well, no.. I'm just telling you our experience with the downstream solution
<robclark>
I'm a bit skeptical that the "compositor should just say how much to boost and when" approach, because of current architecture of our compositor.. which is not to say that it will always be like that forever
<robclark>
but if that was the upstream approach.. I could see us living with our current downstream solution for the time being
* dcbaker
adds delete classic drivers to the 22.0 milestone
<robclark>
MrCooper: also.. I'm not really sure that even the compositor has all the necessary info.. it doesn't know how the window/surface/whatever that has focus is going to react to the input event
<MrCooper>
right, but my point is the display server has strictly more information than the DRM driver
sneil has quit [Quit: Leaving]
<MrCooper>
e.g. the latter can't even know if input from a mouse-ish device will result in any change for the HW cursor
<zmike>
dcbaker: 😎
<robclark>
MrCooper: fair.. but at the end of the day it is some amount of heuristics and guesswork, and IME it is ok to be wrong some of the time and boost when you don't need to..
sneil has joined #dri-devel
camus has joined #dri-devel
<vsyrjala>
how much have people though about security implications of passing input devices to some gpu process?
alyssa has left #dri-devel [#dri-devel]
<steev>
use case?
camus1 has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
<ajax>
vsyrjala: careful, you might accidentally write a program that lets a human control what gets displayed
camus has quit [Ping timeout: 480 seconds]
LexSfX has quit []
ngcortes has joined #dri-devel
ybogdano has joined #dri-devel
nsneck has joined #dri-devel
gouchi has quit [Remote host closed the connection]
LexSfX has joined #dri-devel
drawat has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
pnowack has quit [Quit: pnowack]
<anarsoul>
hey folks, I asked it last night, but didn't get any replies: does it sound crazy to emulate instancing in the driver if hw doesn't support it? And are there any drivers in mesa that do that?
pekkari has quit [Quit: Konversation terminated!]
<anholt_>
the likely emulation I can think of would have surprising performance characteristics where I think you'd be better off just not reporting support for instancing than doing it.
<anholt_>
I don't know of anyone doing instancing.
<anholt_>
(emulation)
<anarsoul>
anholt_: well, I think it'll be more efficient than just duplicating attributes in app
<anholt_>
yeah, you're splitting it to separate draws. that's what I was expecting.
<anarsoul>
anholt_: but I'm not duplicating data
<anholt_>
so, for example, in glamor we use instances when available to reduce a bit of attribute setup overhead. but if you don't have that then we do the work ourselves and still emit one draw.
<anholt_>
if you do your clever thing in the backend, you now take the multi-draw emulation path instead of a single-draw path.
<anarsoul>
anholt_: mali4x0 has attributes descriptors, so I don't need to copy attributes
<anarsoul>
I can just re-use them
<anholt_>
I hear you, I'm just sure this is still going to be worse.
<anarsoul>
why?
<anholt_>
because you split one draw into many?
<anholt_>
every single glyph is now a separate draw
<anarsoul>
yet it's a single job
<clever>
anholt_: are you still active on the rpi drivers?
<anholt_>
clever: no, haven't been in years.
<clever>
ah
<anarsoul>
anholt_: it's a single job for hw, we get 1 interrupt per job, so I don't think it's going to be much different
<clever>
i recently discovered a register that might solve all of my issues
<anarsoul>
also it will have better cache hit rate
<anarsoul>
since attribute buffers will be re-used for each instance draw
<clever>
SCALER_DISPECTRL_SECURE_MODE
<anarsoul>
but yeah, I guess it will need some testing
<anholt_>
anarsoul: I'm telling you my expectations, which is that the per-draw overhead is high enough to be very relevant and this method will be disappointing.
<anarsoul>
anholt_: OK, got you. I'll do some benchmarking for sure if I ever implement it
<imirkin>
anarsoul: anholt_: for an alternate take, the "native" way of doing instancing on nvidia is to send in multiple draws
<imirkin>
you set a special flag which tells it to advance the instance id, but other than that it's just a draw
<anholt_>
imirkin: that sounds plausible, but per-draw attribute updates don't
<cmarcelo>
alyssa: yeah but from a quick skim seem porting up the unittests had no big surprises
<airlied>
their vulkan driver is their opengl driver
<alyssa>
cmarcelo: indeed
<alyssa>
airlied: Arm too
<anholt_>
interesting! good to know.
<alyssa>
vulkan, opengl, and opencl all in one for mali
<airlied>
clang is the main reason i dont try it
<airlied>
like you get llvm for opengl no matter what, but clang is a bigger dep
mattst88 has joined #dri-devel
mattst88 has quit []
mattst88 has joined #dri-devel
<gawin>
a bit offtopic, but maybe state trackers should have their unified naming scheme? under each phoronix's article/reddit's thread there's a mess
mattst88_ has joined #dri-devel
<jenatali>
jekstrand: We've got folks interested in smaller compiler binaries too FYI. Outside of removing strings or trying to compress nir_opt_algebraic we didn't see any real low hanging fruit
<dcbaker>
jenatali: have you tried using lto/ipo/wpo? IIRC that can help with binary size quite a bit
<jekstrand>
I do think someone should try what I suggested above for nir_builder
<jekstrand>
I think that's likely to make a bigger difference than you'd think.
<jenatali>
dcbaker: The majority of the size is data. Don't think LTO really helps there
<dcbaker>
:/
mattst88 has quit [Quit: leaving]
mattst88_ has quit []
mattst88 has joined #dri-devel
<gawin>
jenatali: removal of non gallium drivers
<jenatali>
gawin: The specific thing I want smaller is actually *just* a compiler, the size of the source or the size of drivers built from the source doesn't matter
<gawin>
ah, then it's gonna be difficult
<jenatali>
Yep :)
mclasen has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
Walter has joined #dri-devel
Walter is now known as Walter_
<Walter_>
Hello, is there any header in mesa that can be used in a gallium frontend that relates to the display and info about it, and is there another header or group of them relating the windows and changing the contents of a window
camus1 has joined #dri-devel
mclasen has joined #dri-devel
nchery has quit [Quit: Leaving]
Haaninjo has quit [Quit: Ex-Chat]
camus has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.3]
Walter_ has quit [Remote host closed the connection]
khfeng has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
<alyssa>
jenatali: have you tried rewriting it in rust?
<alyssa>
🙃
<jenatali>
Y'know, I haven't
<mattst88>
"well there's your problem"
ybogdano has joined #dri-devel
<daniels>
alyssa: is that why you wrote agx in rust?
<alyssa>
daniels: exactly
danvet has quit [Ping timeout: 480 seconds]
<ngcortes>
anybody got a recommendation for a stable kernel on adlp?
<ngcortes>
been trying various flavors of drm-tip on our j step boards and drm-tip seems to boot like 1 out of 5 tries :/