ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
Daanct12 has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #dri-devel
<karolherbst>
jenatali: for Buffer/Image mapping you always create a staging buffer for the map, aren't you?
<karolherbst>
mhh and then you migrate to host memory
<karolherbst>
this part of the API is really annoying :(
pallavim has joined #dri-devel
sobkas has quit [Read error: Connection reset by peer]
<jenatali>
Yep
sobkas has joined #dri-devel
<jenatali>
We'll, for alloc host memory buffers, they're already in host mem so I just synchronize. For everything else there's a staging buffer
alyssa has joined #dri-devel
* alyssa
wonders why drm-shim isn't working for her right now
<alyssa>
is drm-shim down for anyone else? :-p
<alyssa>
MESA-LOADER: failed to retrieve device information
<alyssa>
I guess is the smoking gun
slattann has joined #dri-devel
<jenatali>
karolherbst: There's part of me that wishes we spent the time to improve gallium for our CL work... But in hindsight it would've really taken a lot to get the same design we're at right now I think
<alyssa>
Oh, gahhhhh
<alyssa>
libdrm was built against an old version of glibc, mesa against a new one, they disagreed about fstat vs xstat syscall, shimmed the wrong one
<alyssa>
kind of horrible, but rebuilding libdrm solved.
JohnnyonFlame has quit [Read error: No route to host]
JohnnyonFlame has joined #dri-devel
<alyssa>
OAOBOAn
<HdkR>
True facts
agx has quit [Remote host closed the connection]
agx has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
bmodem has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
agd5f has quit [Remote host closed the connection]
<orbea>
fwiw this segfaults for me: 'mpv --no-config --gpu-api=vulkan', updating mesa from 22.2.0 to the recent git fixed it. Might be only with musl :shrug:
agd5f has joined #dri-devel
bmodem1 has joined #dri-devel
<orbea>
vkcube worked as did mpv + opengl
bmodem has quit [Ping timeout: 480 seconds]
cheako has quit [Quit: Connection closed for inactivity]
jewins has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
slattann has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
tzimmermann has joined #dri-devel
fab has joined #dri-devel
<vsyrjala>
mdnavare: i don't see what the problem is with userspace asking for vrr and not getting it due to the display not supporting it. that userspace is stupid, let it be stupid
<jljusten>
daniels: ah, so maybe worth assigning to Marge again?
<daniels>
jljusten: yeah, it looks transient
kts has joined #dri-devel
fab has quit [Quit: fab]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
kts has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<jadahl>
mdnavare: the intended approach is to not allow modesets for vrr changes to be sure that there are no disruptions or anything
<vsyrjala>
the problem with that is increased power consumption due to having to run the hardware at the highest dotclock
<vsyrjala>
it might be nice to have some kind of high level prefer low power vs. prefer no flickers/etc. knob
MajorBiscuit has joined #dri-devel
<jadahl>
vsyrjala: could it be tied to the power profile? then again, wouldn't want to do anything causing blinks when changing that either
<vsyrjala>
i would prefer my display to blink when i yank the ac adapter if it means the battery will last longer
<jadahl>
sure, but these blinks are still a pretty sad ux :(
<vsyrjala>
sure. hence it should be something the user opts into
<jadahl>
thats also not very nice. one shouldn't have to go into some option to select "make video playback better YES / NO"
<jadahl>
and we'd need to have a per driver allow/deny list for making things automatic, since we can't discover whether toggling vrr will or will not require a mode set
<jadahl>
unless one tries and fails, but thats quite annoying
<vsyrjala>
if the user has opted into the "prefer low power" thing, then allow the modeset. otherwise don't allow them
vliaskov has joined #dri-devel
Major_Biscuit has joined #dri-devel
<jadahl>
the default will still be a "be smart" thing, and if that means unnecessary power consumption because of this it isn't very good ither
<vsyrjala>
there is no way to win with current hw
<jadahl>
a question: what's the difference between running at the highest dot clock and using the preferred and likely highest/fastest resolution?
<vsyrjala>
i guess often the preferred mode is the one with max refresh rate. but i've also seen edp vrr panels where that is not the case
mvlad has joined #dri-devel
<jadahl>
i see. anectdotally, looking at the panel I have, it looks like the preferred is the max, with it being vrr capable
MajorBiscuit has quit [Ping timeout: 480 seconds]
<vsyrjala>
btw my low power preference also applies w/o vrr. i'd prefer to switch to the lowest refresh rate available when on battery power, even if that blinks
<jadahl>
would be nice if we could know up front if toggling vrr works without a mode set ...
<jadahl>
but anyhow, knowing that it can't be fixed with current hw is useful, that leaves us with fewer options, but still need to make it work with what we have
<vsyrjala>
it can be fixed
<jadahl>
with a cap or something?
<vsyrjala>
we should be able to just turn vrr on/off w/o a full modeseet
<vsyrjala>
just a simple matter of coding
<jadahl>
but htat's with the worsened battery life as a side effect wasn't it?
<vsyrjala>
yeah, you need to actually use a mode with the high dotclock (and just very long vblank to reduce the refresh rate). then toggling vrr is just a matter of allowing the vblank length to vary
<vsyrjala>
but for lowest power you want to rather reduce the dotclock
<jadahl>
i'll write some notes..
kts has quit [Quit: Konversation terminated!]
<vsyrjala>
on some edp panels we can now actually change the dotclock w/o a modeset as well. but i don't think that is meant to work with external displays, even if they can do vrr
<MrCooper>
do monitors actually advertise multiple VRR capable modes with different dotclocks in practice?
<MrCooper>
hmm, not really relevant I guess
<vsyrjala>
i think a bunch of edp monitors (what i've mostly been looking at recently) had 60hz and say 300hz modes. and vrr range is 48-300hz
<vsyrjala>
the 60hz mode might be the preferred one
<jadahl>
could we set a vrr capable mode vs a non-vrr mode, so that we, depending on the power profile and mode used can select whether modeset is required or not?
<jadahl>
e.g. if we already use the fastest mode, then we can togggle the vrr without modesets, but if we selected a slower, we would require a modeset
<jadahl>
I'm assuming we can't do that right now without making a bunch of implementation detail assumptions
tursulin has joined #dri-devel
jkrzyszt has joined #dri-devel
<vsyrjala>
that's more or less how it should work with i915 (apart from us currently not skipping the modeset when we can). the actual modeline specified by the user dictates the real dotclock. so if they picked something that has low dotclock then no vrr for them (or reduced vrr range). if they used high dotclock then full vrr range is available
<jadahl>
well it might work like that but its not predictable from userspace
<jadahl>
we'd need a flag on the mode or something to know
<vsyrjala>
the mode shouldn't really matter, assuming you only change the vblank length
fab has joined #dri-devel
<jadahl>
i mean the mode matters as if I select a mode with a non-fastest pixel clock, then vrr can't be made to work
<jadahl>
(without modeset)
<vsyrjala>
well it can work, just with a reduced range. but you asked for the low dotclock so presumably you know what you are doing
<jadahl>
that sounds like a good compromise really
<jadahl>
though it'd mean that if the preferred mode is the non-fastest, enabling vrr wouldn't enable the refresh rates that exceed the selected mode
<jadahl>
maybe thats how it should work ... don't require allow-modeset and clamp the vrr range to the selected mode
<jadahl>
assuming that wouldn't make power consumption worse
<vsyrjala>
yeah. i'm just looking at an edid here btw that does have 60hz preferred mode with low dotclock, and a second 300hz mode with high dotclock
<jadahl>
interesting..
<vsyrjala>
what we should perhaps do is add a 60hz variant of that 300hz mode with just long vblank length
<vsyrjala>
the you could ask to run at fixded 60hz, but still be able to switch to 300hz vrr mode w/o a modeset
<jadahl>
yea. question is how to distinguish that from the "real" 60hz mode?
<vsyrjala>
right
<vsyrjala>
dunno
<jadahl>
a new mode flag
<vsyrjala>
well they have different timings already, so they are clearly different modes
<jadahl>
"DRM_MODE_FLAG_IM_FASTER_ACTUALLY"
<jadahl>
you mean that if I'd calculate the refresh rate it'd still say 300 Hz?
<vsyrjala>
it would say 60hz. but it would only differ from the 300hz mode by the vblank length, so you know you should be able switch between then using vrr tricks
<jadahl>
hmm i see
<jadahl>
so i'd be able to get 300hz by looking at the vblank length
<vsyrjala>
not really sure what you're saying there. what i'm saying is that the timings are identical apart from vblank length, and the refresh rates will be different (dotclock/htotal/long_vtotal=60hz vs. dotclock/htotal/short_vtotal=300hz)
<pq>
vsyrjala, if the full modeline determines dotclock and everything else, then how does userspace choose a lower fixed refresh rate with that dotclock? What's the UAPI for this? Manually increasing vtotal to control non-active time starting from e.g. that 300 Hz mode, down to the VRR range minimum?
<pq>
so I'm thinking userspace would do something like this:
<pq>
find the highest rate (dotclock or refresh?) mode, use that as the template but increase vtotal to achieve the desired fixed refresh rate, make sure it's within the VRR range, and program that custom mode.
<pq>
then any mode derived like that will likely not require a full modeset?
<pq>
bonus point for the kernel not having to guess which "VRR capable" refresh rates to manufacture additional modes for, and no confusing in userspace trying to tell them apart.
<jadahl>
vsyrjala: mostly thinking of how userspace can discover what kind of mode it is, and use it differently
<vsyrjala>
pq: yeah, i think userspace could just do that. assuming someone makes the "no full modeset needed" part work in i915 ;)
<vsyrjala>
i guess one question is whether the kernel should synthesize some modes like that, or just leave it all up to userspace?
<emersion>
amdgpu synthesizes some modes, iirc
<emersion>
but i don't really like it
<vsyrjala>
yeah, i remember some patch like that, but didn't actually read it to see what it did
<emersion>
we discussed some vrr_min/vrr_max props also
<jadahl>
(have to run out for a bit)
<emersion>
which would be pretty nice to have
<pq>
whether the driver synthesises modes or not, userspace still needs all of the same logic to tell those modes apart than it needs for synthesizing those modes itself.
<pq>
here I'd say: you want a friendly hand-holding API? Make it in a userspace lib.
<pq>
the kernel just has to document that this kind of "smart VRR logic" is expected of userspace, so that userspace has docs on what to implement exactly and driver devs know what to expect from userspace.
<vsyrjala>
fair. i was pondering if it might somehow help existing userspace work more sensibly, but i guess not really since it wouldn't know to automagically change between the 60hz vs. 300hz modes anyway
<emersion>
libdisplay-info \o/
<pq>
if a driver doesn't understand or agree, it simply fails the atomic commit without ALLOW_MODESET, and that's good enoung IMO.
<pq>
emersion, not libxcvt? :-)
<emersion>
tbh i was about to re-implement libxcvt in libdisplay-info
<pq>
oh
<vsyrjala>
same algorithm, all new bugs :P
<emersion>
yeah, i have a WIP patch which does it from the spec
<emersion>
but it's a whole mess
<emersion>
vsyrjala: we have tests
<pq>
well, I guess extending libdisplay-info scope like that is ok
<vsyrjala>
tests... someone should probably think about that for the in-kernel edid parser too
lynxeye has joined #dri-devel
<emersion>
GTF and CVT mode generation is required to be able to make use of the EDID mode list
<pq>
aha, didn't know that
<pq>
buuut...
<emersion>
some modes are "width, height, refresh, and use GTF/CVT to know the rest"
<pq>
userspace is not supposed to do that, is it?
fahien has joined #dri-devel
<emersion>
not compositors
<emersion>
compositors should use the kernel mode list
<pq>
who else would use libdisplay-info?
<emersion>
di-edid-decode
<pq>
edid-decode prints detailed modelines for such modes?
<vsyrjala>
someone should probably also look at using libdisplay-info in igt so we don't need yet another parses there
<vsyrjala>
though igt also wants to generate some edid content, so maybe we can't really escape it until libdipslay-info can generate edids too (i presume it can't)
<emersion>
pq, yes
<emersion>
vsyrjala: at the moment it can't but swick wanted to add this
<pq>
emersion, why not make di-edid-decode simply use libxcvt? No need to expose that functionality if libdisplay-info API.
<pq>
*in
* vsyrjala
dreams of some point and click edid editor
<emersion>
pq, to reduce the number of deps mostly
<emersion>
pq, compositors want GTF/CVT to generate custom modes too
<ccr>
The Secret of the EDID Island
<emersion>
and picking between GTF, CVT, CVT RBv1/v2/v3 is not trivial
<emersion>
so, if we have a high-level API "generate the best custom mode for width/height/refresh for this EDID", that'd be nice
<pq>
emersion, compositors can use libxcvt too. Why would a *compositor* need to pick between those?
mattst88_ has joined #dri-devel
<emersion>
a compositor needs to choose, libxcvt provides separate functions for each
mattst88 has quit [Ping timeout: 480 seconds]
<pq>
emersion, how is that kind of API not trampling all over the "kernel provides the modes" principle?
<emersion>
tbh i'd rather not have libxcvt
<emersion>
it's too small of a lib
<pq>
the same can be said about libdisplay-info.
<pq>
and it doesn't get any bigger by joining the two, really
<emersion>
libdisplay-info is not a 100 LoC lib
rasterman has joined #dri-devel
<emersion>
if it was, i'd just copy over the code in my compositor
<emersion>
which is exactly what i've done for CVT/GTF
<pq>
The compositor does not need to choose between GTF, CVT, etc. The end user makes that choice when demanding a custom mode.
<emersion>
no, not in my compositor
<emersion>
in my compositor, the user just sets width/height/refresh
<emersion>
and the compositor does the Right Thing™
<pq>
how can the compositor know what the right thing is?
<emersion>
from the EDID
<vsyrjala>
what if the display doesn't declare support for gtf/cvt/etc? the compositro will refuse?
<emersion>
monitor ranges etc
<pq>
so you are looking at EDID for modes and ignoring the kernel mode list?
<emersion>
pq, only for custom modes
Mangix has quit [Read error: No route to host]
frankbinns has joined #dri-devel
<vsyrjala>
also what if the kernel filtered out some edid modes due to hw constraints, but the user wants to use that *exact* mode anyywa and it doesn't conform to gtf or cvt?
<pq>
hmm, ok... but it still feels like this "custom mode API" makes it far too easy to just completely ignore the kernel mode list, even if you know better in your projects.
<emersion>
pq, weston config has a way to specify a custom modeline
<emersion>
that's exactly the same
<pq>
emersion, no, it's not. That's an end user interface. I'm talking about compositor developers' code.
<emersion>
i don't understand
<pq>
why would compositor developers bother looking at the kernel mode list at all, if a single call to libdisplay-info gives them any mode they could want?
rasterman has quit [Quit: Gettin' stinky!]
<emersion>
so what do you suggest? make it extra difficult for compositors to do this, by copy-pasting the same code in each?
Mangix has joined #dri-devel
<emersion>
it doesn't makes sense to me
<emersion>
just document the function as best-effort, may not work, use the kernel list
<pq>
yes, make them use libxcvt and libdisplay-info separately, needing to painfully tie them together. It's still possible, but painful enough to not fall into the trap.
<emersion>
…
<pq>
sicne we cannot outright forbid manufacturing custom modes
<emersion>
libdisplay-info already has an API to enumerate modes
<pq>
doing suspect things should be hard, and doing the right thing should be easy
<emersion>
that's Harmful, because compositors could be tempted to use that instead of the kernel list
<pq>
yes
<emersion>
thus half of libdisplay-info should be removed
<emersion>
^ exactly the same argument
<pq>
luckily that API is still low-level API, so there is some barrier to use it.
<pq>
the high-level API should never grow mode listings functionality
<emersion>
(brb)
<vsyrjala>
all i wish is that compositors allow fully custom modelines. would save me some grief when dealing with angry users' bug reports
srslypascal is now known as Guest1132
srslypascal has joined #dri-devel
<pq>
we do, sure
<pq>
Weston already does, it just doesn't have or use any GTF/CVT or other modeline generator. The user gets to define the mode in full.
pcercuei has joined #dri-devel
Haaninjo has joined #dri-devel
<vsyrjala>
yeah, i like that because users can be very picky about their modelines. any automagic hand holding ther would generally be not helpful when dealing with them
Guest1132 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Quit: Leaving]
srslypascal has joined #dri-devel
rasterman has joined #dri-devel
sarahwalker has joined #dri-devel
kts has joined #dri-devel
bmodem has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<jadahl>
vsyrjala: on the other hand, shoving custom modelines at some drivers causes them to fail the commits..
bmodem1 has quit [Ping timeout: 480 seconds]
<MrCooper>
with great power comes great responsibility
<karolherbst>
jenatali: yeah... though I think I came up with an idea how to make this mapping work without requiring extra copies
<karolherbst>
could create a coherent/persistant shadow resource, which we should be able to map directly, so the only copies we'd have to do is when we sync the content
<karolherbst>
so either we can map directly, or fallback to that
kts has quit [Quit: Konversation terminated!]
pallavim_ has joined #dri-devel
kts has joined #dri-devel
<dj-death>
if I need llvm-13 for CI, what's the way to go about upgrade it?
pallavim has quit [Ping timeout: 480 seconds]
pallavim has joined #dri-devel
<MrCooper>
dj-death: the CI build image already has LLVM 13
<MrCooper>
the *build* image, not the test images yet
pallavim_ has quit [Ping timeout: 480 seconds]
<dj-death>
hmm
<MrCooper>
the former should serve as an example though
<dj-death>
I'm confused, I'm using the test image when building on CI?
Surkow|laptop has quit [Quit: 418 I'm a teapot - NOP NOP NOP]
dakr has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
newbie has joined #dri-devel
newbie has quit [autokilled: This host violated network policy. Contact support@oftc.net for further information and assistance. (2022-09-22 11:39:21)]
slattann has quit [Quit: Leaving.]
Surkow|laptop has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
itoral_ has joined #dri-devel
pallavim_ has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
itoral has quit [Ping timeout: 480 seconds]
pallavim has quit [Ping timeout: 480 seconds]
Lucretia has quit []
Lucretia has joined #dri-devel
gio has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
gio has joined #dri-devel
<pq>
I need to do the equivalent of glReadPixels in ES 3.0 with the packed image origin at top-left, not bottom-left. Any... ideas?
<pq>
I found GL_MESA_framebuffer_flip_y, but it doesn't work without FBOs, even if I understood how it works.
<pq>
it's for Weston's screenshooting, I'd like to get rid of a temporary CPU copy just to y-flip the image.
<ajax>
pq: also spelled MESA_pack_invert in big gl
<dj-death>
what the debian version used for CI?
<dj-death>
naming implies testing
<dj-death>
but there are references to bullseye which is now stable
<DavidHeidelberg[m]>
dj-death: oh that's you?
<dj-death>
yeah
Duke`` has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
fxkamd has joined #dri-devel
<MrCooper>
dj-death: bullseye
<MrCooper>
dj-death: 'testing' refers to builds for test jobs
Company has joined #dri-devel
<dj-death>
ah okay
<dj-death>
and bumping to bookworm would be a bad idea?
<MrCooper>
yep
<dj-death>
okay
kem has quit [Ping timeout: 480 seconds]
sarahwalker has quit [Remote host closed the connection]
<dj-death>
I guess downloading a couple of packages from testing would be better
rsripada has quit [Quit: No Ping reply in 180 seconds.]
<MrCooper>
it would turn rebuilding the CI images into a lottery
rsripada has joined #dri-devel
<MrCooper>
dj-death: no can do in general, since it pulls in low-level libraries like glibc from testing
<shadeslayer>
I've usually found testing to be OK, packages should be installable ....
<dj-death>
so my only option is build from source
<MrCooper>
i.e. still the same lottery
<MrCooper>
shadeslayer: it can be fine, until it suddenly breaks the next day
<MrCooper>
dj-death: what is it about?
agd5f has quit [Read error: Connection reset by peer]
<dj-death>
MrCooper: llvm to spirv translator
agd5f has joined #dri-devel
<dj-death>
MrCooper: which is available in debian but not the version I need to match my requirement of clang/llvm 13
<dj-death>
I mean available in debian stable but not the right version
<DavidHeidelberg[m]>
MrCooper: really that bad idea? I was thinking about it, but only when issues with bullseye reach some hardly manageable level
<MrCooper>
dj-death: right; building from source should be straightforward for that, we already did it before, check out the Git history for .gitlab-ci*
<MrCooper>
DavidHeidelberg[m]: done it before, got the scars to prove it
<DavidHeidelberg[m]>
MrCooper: I believe you :D
kem has joined #dri-devel
<MrCooper>
we used some packages from testing early in the bullseye cycle, which worked fine for some time, but then broke
* ccr
pon-ders the mysteries of the universe
<ccr>
zmike, probably not interesting to you, but it bothered me personall :P - regarding https://gitlab.freedesktop.org/mesa/mesa/-/issues/7165 .. as I mentioned on the ticket, I have two nearly identical systems and the issue presents only on the other one. today I took the effort to transplant the system SSD from the "does not hit assert" system to the "does hit assert" system and the assert was NOT hit. so
<ccr>
it must be a software stack difference somehow .. but even those are rather minimal. anyway, very weird.
<zmike>
timing and xserver interactions are everything
<dj-death>
MrCooper: just to understand correctly, stuff that is built for building mesa is in x86_test-base.sh ?
<dj-death>
MrCooper: I'm very confused by build and test scripts
<MrCooper>
nope 'test' means the resulting image is used only for test jobs
<ccr>
zmike, yeah, it has a sense of a race-condition thing of some kind. oddly it is/was 100% reproducable on one and not at all on the other.
<zmike>
we got it though 💪
<dj-death>
MrCooper: what does a test job do?
<ccr>
zmike, but thanks for looking into it never the less, you rock
<zmike>
all bugs must be fixed
<zmike>
except the ones I don't feel like fixing
<MrCooper>
dj-death: run tests, e.g. piglit or CTS
<ccr>
:)
<dj-death>
MrCooper: I see, thanks
<MrCooper>
no worries
<MrCooper>
test jobs use the Mesa binaries built by a build job, passed via artifacts
aravind has quit [Ping timeout: 480 seconds]
ella-0 has joined #dri-devel
ella-0- has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
devilhorns has quit []
agd5f has quit [Remote host closed the connection]
agd5f has joined #dri-devel
pallavim has joined #dri-devel
<orbea>
karolherbst: is it true that mesa can no longer build if rust is installed even if rusticl is not enabled? Someone showed me this error message: err invalid option: 'rust_std=2021'
<orbea>
*is not installed
<karolherbst>
orbea: mhh, that probably comes from rustc being too old
bmodem has quit [Ping timeout: 480 seconds]
<orbea>
they have no rust on their system
<karolherbst>
huh...
<orbea>
this is what they get for experimenting with niche distros :P
<karolherbst>
builds fine here
<orbea>
hmm, wierd, must be a distro issue then
<karolherbst>
what's the meson version?
<karolherbst>
could also be due to meson being too old
<orbea>
plausible, I'll find out
<orbea>
oh, they don't even have meson, they have muon lol
<karolherbst>
orbea: okay.. meson without that commit also doesn't care
<orbea>
i dont see much in the way for rust greping the muon repo
<karolherbst>
and once I enable rusticl, it complains about not being 0.61.4 or newer, so with meson everything is fine
<orbea>
yea, seems false alarm :)
pallavim_ has quit [Ping timeout: 480 seconds]
<karolherbst>
if moun wants to stay a drop in replacement, I guess they have to keep up a little better
<orbea>
yep...
rasterman- has joined #dri-devel
rasterman has quit [Read error: Connection reset by peer]
srslypascal has quit [Remote host closed the connection]
rasterman- has quit []
srslypascal has joined #dri-devel
rasterman has joined #dri-devel
MajorBiscuit has quit [Quit: WeeChat 3.5]
<ajax>
:/
<ajax>
bind_framebuffer, when framebuffer = 0, resets both the read and draw framebuffer bindings to the default framebuffer
<ajax>
even if you only said GL_DRAW_FRAMEBUFFER for target
ElementW has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<ajax>
so if you want one of read/draw to be an fbo and the other to be the default fb, you have to set the default fb one of read/draw first, then flip the other to the user fb
<ajax>
o
<ajax>
so the half-and-half state is reachable, but only in a weird way, and i can't find any good justification for that in the spec
<ajax>
anyone have any guesses?
<ElementW>
Does GLX have an equivalent of EGL's EGL_DRM_RENDER_NODE_FILE_EXT? I'm trying to grab an fd to the opened render node