ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Namarrgon has quit [Quit: WeeChat 3.7.1]
carbonfiber has joined #dri-devel
<jenatali>
jekstrand: I'm getting back to looking at WSI a bit, was going to try to get resize working by adding DComp into the mix, and... dcomp.h can't be included in C :(
<jenatali>
How terrible would it be to add a C++ source file just for hosting DComp in vulkan/wsi?
Namarrgon has joined #dri-devel
<jenatali>
(The problem is that they use overloaded methods, so you end up with multiple VTable entries with the same name...)
<karolherbst>
airlied: I probably just insert a nir_lower_bit_size call somewhere into radeonsi finalize_nir I guess...
FireBurn has joined #dri-devel
pcercuei has quit [Quit: dodo]
inverted has quit []
inverted has joined #dri-devel
yuq825 has joined #dri-devel
inverted has quit []
inverted has joined #dri-devel
columbarius has joined #dri-devel
mackerelian has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<jekstrand>
jenatali: What is dcomp?
oneforall2 has joined #dri-devel
<jenatali>
jekstrand: DirectComposition. Lets you manipulate the visual tree of the desktop with more control than a traditional window
<jekstrand>
Ah
<jenatali>
We'll want to bind a swapchain to a window independently of the swapchain lifetime to be able to handle the Vulkan swapchain progression design
<jekstrand>
jenatali: If Vulkan Windows WSI has to be C++, I guess it has to be C++.
<jenatali>
And DComp is the only way I know to do that
<jekstrand>
Or we can have some C++ which provides C wrappers.
<jenatali>
Well... It has to be C because the Vulkan runtime headers are C. So yeah, C wrappers
<jekstrand>
Oh, right... Yeah, we had problems with that with Dozen didn't we?
<jenatali>
Yup
<jekstrand>
*sigh*
<jenatali>
Still a little salty about TBH but oh well
<jekstrand>
I don't even remember what the problems were.
<jenatali>
Designated initializers are C++20 and have more restrictions than C
<jenatali>
And struct initialization uses different syntax
<jenatali>
And people didn't want to require the Vulkan runtime headers to use the subset that's compatible with both
<jekstrand>
Yeah, that's ringing bells. I'm trying to find the MR so I can see what the problems were.
<jekstrand>
Yeah, I see that one. I thought maybe there was an MR against the common code that I NAK'd.
<jenatali>
No, at this point the Vulkan headers still compiled as C++, but it was causing friction for adding new stuff
<jekstrand>
Ok....
<jekstrand>
I believe you. I'm just not seeing why it would cause a problem. 🤷
<jekstrand>
We use designated initializers all over the code but not typically in header files.
* jenatali
shrugs
<jenatali>
It was long enough ago that some of the finer details are starting to get fuzzy
<jekstrand>
Fair
<jekstrand>
In any case, if you want to try re-compiling wsi_win32 as C++ and see how bad it is, feel free.
<jenatali>
There definitely are designated initializers in headers, otherwise we wouldn't have added the C++20 requirement
<jekstrand>
It'll mean c++ runtime for Windows drivers but they either already have that somewhere (Zink) or lavapipe which depends on LLVM so meh.
<jenatali>
GLSL types
<jekstrand>
And that.
<jekstrand>
*sigh*
<jekstrand>
I believe you about designated initializers. I just don't know where. 😅
<jekstrand>
I guess if you tried to compile foo_entrypoints.c as C++, that would be a problem.
zf has quit [Read error: No route to host]
<jenatali>
Yeah I don't remember where, and maybe they've moved out of headers since, but they were there for sure
<jekstrand>
Ok
zf has joined #dri-devel
<jenatali>
Lemme log into the work PC and give it a quick try changing the file extension and let's see what happens :P
<jekstrand>
hehe. Ok
<jenatali>
Alright well wsi_common_win32's current includes don't have a problem with C++, though the file doesn't quite build cleanly without changes
<jenatali>
I'm starting to remember that it was some macros that were problematic
<jenatali>
So, not just including the header, but specific code you'd want to use out of it
<jekstrand>
That's believable
<jekstrand>
I know the shader_module_for_nir macro won't work with C+
<jekstrand>
*C++
<jenatali>
Oh though I guess my build env is configured as C++20 I think so I'm probably not hitting designated initializer errors if there are any lurking
<jenatali>
Anyway, I'll figure out the right thing, either converting it or adding a C interface for DComp, just wanted to make sure there weren't immediate objections
nchery has quit [Ping timeout: 480 seconds]
<jekstrand>
ok
<jekstrand>
Yeah, no immediate objections.
gbelgurr has quit [Ping timeout: 480 seconds]
<airlied>
karolherbst: 19768 might help saturate your cpu a bit more (or it might fail completely)
<karolherbst>
and here I was thinking about going to bed
<DemiMarie>
jenatali: timezone issue, you’re looking at yesterday’s logs 🙂
<jenatali>
Hah I'd believe that
<DemiMarie>
Today’s logs do have the messages
<jenatali>
Nevermind then
<DemiMarie>
Thanks for trying to be helpful, though!
<DemiMarie>
The reason I asked about fuzzing is that Qubes OS currently does all rendering in software, as current means of exposing GPU acceleration to guests either require enterprise GPUs or have far too much attack surface. virtGPU native contexts might change this, but only if the GPU driver is robust against malicious input, which at a minimum means fuzzing.
srslypascal is now known as Guest1644
srslypascal has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
Guest1644 has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
Duke`` has quit [Remote host closed the connection]
kem has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
srslypascal is now known as Guest1645
srslypascal has joined #dri-devel
mhenning has quit [Quit: mhenning]
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
kem has joined #dri-devel
Guest1645 has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest1646
srslypascal has joined #dri-devel
Guest1646 has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
bgs has joined #dri-devel
nchery has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
ahajda has joined #dri-devel
fab has quit [Quit: fab]
Company has quit [Quit: Leaving]
Leopold_ has quit [Remote host closed the connection]
dcz_ has joined #dri-devel
bgs has quit [Remote host closed the connection]
kts has joined #dri-devel
kts has quit []
darkbasic5 has quit [Remote host closed the connection]
dviola has joined #dri-devel
kts has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
danvet has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
Daanct12 has quit [Read error: Connection reset by peer]
frieder has quit []
frieder has joined #dri-devel
Daanct12 has joined #dri-devel
rasterman has joined #dri-devel
tzimmermann has joined #dri-devel
pochu has joined #dri-devel
tursulin has joined #dri-devel
macromorgan is now known as Guest1654
macromorgan has joined #dri-devel
MajorBiscuit has joined #dri-devel
Guest1654 has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
kxkamil has quit []
YuGiOhJCJ has quit [Remote host closed the connection]
fab has joined #dri-devel
jkrzyszt has joined #dri-devel
sgruszka has joined #dri-devel
lynxeye has joined #dri-devel
swalker__ has joined #dri-devel
rasterman has quit [Read error: Connection reset by peer]
rasterman has joined #dri-devel
<tzimmermann>
javierm, i intend to merge the nomodeset patches
<MrCooper>
DavidHeidelberg[m]: FWIW, "alpine-build-testing" would be more consistent with other job names; "alpine-testing" implies the resulting binaries are used in test jobs
<danvet>
airlied, hopefully the reply I typed isn't too angry, yours is really good in that regard
pcercuei has joined #dri-devel
<javierm>
danvet: I find it very good, more polite than is deserved IMO after the pile of insults in the commit message...
ngcortes has quit [Read error: Connection reset by peer]
<danvet>
you've also looked a bit at that handover stuff, and frankly I'm at loss
<danvet>
unless it's just the nvidia blob
<emersion>
hm i guess one downside is that atomic=1 existed before atomic=2
<emersion>
so one would need to fallback to atomic=1 if atomic=2 gives EINVAL
<emersion>
to support kernels before 2019
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #dri-devel
<danvet>
emersion, yeah so maybe it's a "should try atomic=2 before trying atomic=1"
<MrCooper>
karolherbst: any luck yet with solving that rusticl build failure with valgrind support enabled? Someone created https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19773 to work around it by breaking the default auto value of the valgrind option :/
<karolherbst>
MrCooper: can't be fixed with current meson :/
<javierm>
danvet: Ok, I'll take a look to that and try to reproduce with other GPUs
<karolherbst>
so the problem is, that the bindgen things can't take any dependency objects, which I'd need to do here
<javierm>
danvet: Not today though, right now arguing with gregkh about some driver core changes. I for sure know how to choose my battles :P
<MrCooper>
karolherbst: aww
<karolherbst>
probably should fix it, but I think dcbaker had a patch for that somewhere? Dunno
<danvet>
javierm, link for the driver core thing? for entertainment :-)
<karolherbst>
let's see if I can deal with the todos there...
* danvet
cries in optional dependencies
<danvet>
javierm, yeah I think this would be entertaining at least
<danvet>
plus maybe useful, since we're pushing pretty hard to rely on this in drm, and the occasionally "the kernel fails to guess what config I really want" report pops up
<danvet>
especially around optional deps
<danvet>
which imo are an entirely impossible concept, but people really love them
<danvet>
(runtime optional to be precise, build time is kinda fine)
<danvet>
jstultz, ^^
<javierm>
danvet: yeah. Something I liked about the probe deferral mechanism is that it was simple and easy to reason about
<javierm>
danvet: it wasn't the most efficient way to probe but it was effective
<javierm>
adding this arbitrary probe deferral timeout just makes things even more fragile IMO
<javierm>
danvet: but it seems that some drivers really have optional deps and could work even if the suppliers are not available, so I'm adding a second workqueue to timeout the devlink enforcing
<danvet>
I think fundamentally it's the runtime optional dependencies
<danvet>
since they require you either have a perfect view of the future, or you just trade regressions and bugs with some timeout bikeshedding
<javierm>
danvet: yeah
<danvet>
build time is fine
<danvet>
runtime optional dep is fundamentally just broken, and you can't really fix it
<javierm>
danvet: yes, I also don't understand how runtime optional dep would work. Because is just relying on whatever was set by the firmware
<javierm>
but as said it seems that's something that people want and have been relying on
<javierm>
I just don't think that drivers with required dependencies should pay the price and disable the probe deferral mechanism
<javierm>
because those drivers could very well probe if there wasn't a timeout
<jani>
tzimmermann: thanks for the ack; enough for merging?
apinheiro has joined #dri-devel
<danvet>
javierm, yeah probably a new EPROBE_DEFER_OPTIONAL or so is needed
<danvet>
and a loooot of changes
<danvet>
plus just not accepting that kind of silliness in drm I think
<javierm>
danvet: well, the current solution is to just stop returning -EPROBE_DEFER and just return -ENODEV or whatever and drivers deal with it
<danvet>
and then put a /* this is unsound duct-tape engineering */ comment above that
<danvet>
javierm, oh is this in the lookup functions, not in what drivers return to get reprobed?
<danvet>
I didnt' look at the code too closely
<danvet>
I figured you need both, to handle all combinations of races
<danvet>
and to actually work EPROBE_DEFER would need udev to kick the kernel and tell it that it has indeed loaded everything
<danvet>
s/udev/userspace/
<danvet>
argh I mean DEFER_OPTIONAL
<danvet>
so that the kernel knows when to switch from DEFER_OPTIONAL to ENODEV
kts has joined #dri-devel
<javierm>
danvet: exactly. We need user-space to tell the kernel, the kernel has no way to know when modules won't be loaded anymore
<javierm>
iommu is just an example, other subsystems like power domains do the same
<danvet>
uh
<danvet>
this looks terrible frankly
<danvet>
luckily didn't creep into drm yet
<danvet>
well I guess the iommu stuff goes boom for drm drivers that need the iommu
yuq825 has left #dri-devel [#dri-devel]
<javierm>
yeah, but it's too non-deterministic. You can either get as a return value -ENODEV (!modules && initcalls_done) or -ETIMEDOUT (deferred_probe_timeout && initcalls_done) or -EPROBE_DEFER
<danvet>
oh the current stuff looks silly imo
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
Daanct12 has quit [Quit: Quitting]
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
<tzimmermann>
jani, it's enough for me
<tzimmermann>
go ahead if you like
<jani>
tzimmermann: thanks
<javierm>
danvet: yeah, personally I would just get rid of all the runtime optional devlinks TBH
<javierm>
either enforce the deps or not but it seems there's a lot of amount of guessing there that makes the whole logic too complex
<lynxeye>
the current static devlinks are horrible, as they try to construct the dependency purely by looking at the DT/whatever. A driver in a given kernel might not even use or know about a specific property, still the dependency is enforced before probe.
<lynxeye>
A much more robust improvement to the current probe deferral handling would have been to just record the dependency when a resource request hits EPROBE_DEFER and don't try to probe the driver again until that dependency is fulfilled.
<javierm>
lynxeye: yes, agreed. But the idea I believe was to use the devlinks to make an ordered probe rather than brute force it which is what -EPROBE_DEFER does
<javierm>
which is OK I think, what I not find acceptable is that then people want to make that enforcement optional and disable the brute force mechanism using a timeout
<javierm>
tzimmermann: I see that you provided some feedback so I assume that you are waiting for a v3?
Leopold has joined #dri-devel
mackerelian has quit []
kts has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
mackerelian has joined #dri-devel
devilhorns has quit []
tchar____ has quit []
tchar has joined #dri-devel
zehortigoza has quit [Remote host closed the connection]
fab has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
Haaninjo has joined #dri-devel
fab has quit [Quit: fab]
<tzimmermann>
javierm, yes. i was hoping for a new iteration
fab has joined #dri-devel
<javierm>
tzimmermann: thanks, that's what I told that person who asked but preferred to confirm with you
<tzimmermann>
the reserved-mem api is awkward IMHO. i was asking to hide it behind something that looks like the rest of the look-up functions in simpledrm
<javierm>
tzimmermann: yeah, I don't know enough to give a proper review but my gut feeling is that this is something that should be in drivers/of or drivers/firmware
<javierm>
tzimmermann: simpledrm just should get a buffer that automagically was setup by platform code IMO
<javierm>
s/setup/obtained somehow
<tzimmermann>
that was my gut feeling too. but the memory comes from the DT, which simpledrm already parses for values.
<tzimmermann>
i guess we'll run into problems with aperture mgmt
<tzimmermann>
because we'd need the reserved memory ranges to maintain aperture ownership
<tzimmermann>
at least if we ever want to move the device mgmt into the aperture code
<tzimmermann>
but for now, it's still ok to have this in simpledrm
fab has quit [Quit: fab]
<javierm>
tzimmermann: right
fab has joined #dri-devel
<javierm>
tzimmermann: another thing is that patch 4/7 partially reverts commit c25b69604fc4 ("drm/simpledrm: Inline device-init helpers")
<javierm>
since you used to have a simpledrm_device_init_mm() before that got in-lined in the probe function
<tzimmermann>
javierm, i pushed back on that change
eballetbo has joined #dri-devel
<javierm>
tzimmermann: ah Ok
<tzimmermann>
it's somewhere in my review
<javierm>
should probably read the whole thread before making comments here then :)
<tzimmermann>
and with a better internal api, the de-inlining isn't necessary
<javierm>
yeah
<javierm>
I wonder though if at some point simpledrm would have to be moved from tiny and split it in different files
<javierm>
because it supports DT, EFI-GOP and now "memory-region" too
<DavidHeidelberg[m]>
MrCooper: good tip, thanks I'll sent MR
<javierm>
tzimmermann: although I've to admit that don't fully understand why the "memory-region" couldn't just be a "reg" property
codingkoopa9 has quit [Ping timeout: 480 seconds]
<tzimmermann>
javierm, so i'm not the only one! :) i also wondered, i've we're cramming too much stuff into simpledrm. there's regular DT, plus sysfb, plus (maybe) reserved mem. and at least the sysfb code is definately differnt from the rest. it could have been a separate driver
<javierm>
tzimmermann: yeah, because at this point simpledrm is neither simple nor tiny :)
<tzimmermann>
:)
<tzimmermann>
i mean, adding a sysfbdrm driver would simplify things. and if the reserved-mem code would eventually go into drivers/of, the simpledrm really comes down to the original meaning of simple-framebuffer nodes
<tzimmermann>
i have a number of more pressing issues to work on, but sysfbdrm is not off the table for me
<javierm>
tzimmermann: yeah. Or we could have a drivers/gpu/drm/firmware or something where we could have all these drivers that could share a set of helpers
<javierm>
tzimmermann: and we could move drivers/gpu/drm/tiny/ofdrm.c there too
<tzimmermann>
IDK. it seems arbitrary to me
ced117 has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: yeah, just to have all the drivers for "firmware provided framebuffers" in the same place
<javierm>
tzimmermann: or maybe split simpledrm in simpler drivers, i.e: sysfbdrm, memregdrm (horrible name but you get the idea), etc
<javierm>
and keep all those in tiny
zehortigoza has joined #dri-devel
<javierm>
tzimmermann: I'm just thinking aloud. What I think that we should require though is a different compatible string for this
<javierm>
tzimmermann: so is not "simple-framebuffer" but "memory-region-framebuffer" or something like that
<javierm>
how to organize the code can be done as a follow-up if needed, but the DT binding can't be changed later
codingkoopa9 has joined #dri-devel
<tzimmermann>
javierm, in solomon, shouldn't it be a default color depth of 1?
<javierm>
tzimmermann: well, the format driver is an emulated DRM_FORMAT_XRGB8888
<javierm>
that's why is set to 32
<tzimmermann>
i mean, the native format is C1. and shouldn't it export that?
<javierm>
tzimmermann: yes, we should but at the time C1 didn't exist and I never went back to look at Geert's patches to add support for that
<tzimmermann>
ah, ok
<javierm>
tzimmermann: it's in my TODO list but since is only used by fbcon, I never really gave it a lot of priority
<javierm>
all user-space is more compatible with XRGB8888
<tzimmermann>
somehow related: in ast, the cursor plane is argb4444. and we export it as emulated argb8888, because there's no userspace for argb4444. otherwise the cursor plane would be useless. only-ever-emulate-xrgb8888 is not the full story :/
<javierm>
tzimmermann: I see... so only-ever-emulate-{a,x}rgb8888 then it is?
<tzimmermann>
probably; no idea
<javierm>
tzimmermann: too many rabbit holes to go down into :)
Company has joined #dri-devel
fab has quit [Quit: fab]
bgs has joined #dri-devel
pochu has quit [Quit: leaving]
ced117 has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
thaytan has quit [Ping timeout: 480 seconds]
thaytan has joined #dri-devel
fab has joined #dri-devel
grayshade[m] has left #dri-devel [#dri-devel]
Duke`` has joined #dri-devel
mhenning has joined #dri-devel
ybogdano has joined #dri-devel
frieder has quit [Remote host closed the connection]
djbw has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
* jekstrand
really doesn't grok isaspec/encode.py
JTL has quit [Ping timeout: 480 seconds]
JTL has joined #dri-devel
Guest1658 has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
sgruszka_ has joined #dri-devel
* jekstrand
builds freedreno in the hopes of better understanding isaspec
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
Major_Biscuit has quit []
junaid has joined #dri-devel
Akari has joined #dri-devel
Peuc has quit [Ping timeout: 480 seconds]
Peuc has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
<jekstrand>
robclark: Are isaspec expressions ever used for anything other than conditions?
<robclark>
they can be used for things like derived fields as well
<jekstrand>
Hrm... ok.
<jekstrand>
Trying to understand why they return int64 rather than bool
<robclark>
and asserts
<robclark>
yeah, derived fields is the main non-bool thing
<jekstrand>
Trying to make a version of encode.py that generates rust. The rust type system is a bit less flexible. :)
<dj-death>
fun times
<robclark>
oh.. that is a thing I hadn't considered yet ;-)
<jekstrand>
:D
<robclark>
I guess you can use `!= 0` for the conditional places where expr is used?
<jekstrand>
I can
<jekstrand>
The question is if I want two different expression handlers, one for conditionals and one for derived fields.
<robclark>
so, the other question.. expr's are just chunks of C code.. which maybe isn't the greatest thing for generating rust version
<robclark>
although, I guess if you know you are only going to generate rust code, you could just make 'em chunks of rust code instead
<dj-death>
sounds like you really need to start your own language so that you can compile it down to C or rust or whatever
* dj-death
looks for the door
<jekstrand>
robclark: Yeah, that's the plan. My expressions will be rust snippets, many of which call accessor methods.
<jekstrand>
dj-death: Get outa here! Even I'm not THAT crazy... :-P
Leopold has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<jekstrand>
For rust, I feel like I almost just want to generate a struct type for each bitfield type in the XML
lemonzest has quit [Quit: WeeChat 3.6]
<linkmauve>
Have a look at how the bitflags crate generates its structs.
<dcbaker>
karolherbst: I sorta wrote some patches based on what you had said we needed, so I didn't want to get too deep into it until I was sure I was working on the right problem :)
<dcbaker>
There were two other things I was thinking about
<dcbaker>
one is that apparently bindgen can be told to use a specific clang
<dcbaker>
so we should probably set that up correctly
ngcortes has joined #dri-devel
<dcbaker>
and then I was wondering about cross compiling...
<karolherbst>
yeah...
<karolherbst>
there is another issue about having multiple libclang/libllvm versions installed and things break
<karolherbst>
it's a weird issue
<dcbaker>
yeah.... we can set the CLANG_PATH env variable if we know that we need to
<dcbaker>
but I want to propose that change separately
<jekstrand>
If I do a struct per bitfield, I would need to use enums to handle overrides.
<cmarcelo>
dcbaker: if you touch that, you probably want to unify the two places thaaat look for llvm/clang in the meson.build files. (there's one toplevel and one inner somewhere)
<jekstrand>
robclark: Do overrides overwrite replace the entire bitset or just parts? If so, how do you know which parts to keep?
<dcbaker>
cmarcelo: I have patches for that, though they're probably 9 months out of date at this point...
rodrigovivi has quit [Ping timeout: 480 seconds]
<jekstrand>
robclark: Or does the override only override the bits specified by it?
<dcbaker>
I might not bother though, since Tom Stellard said he'd be in favor of pkg-config support if patches for llvm arrived...
<cmarcelo>
dcbaker: llvm will accept to have pkg-config?
<cmarcelo>
even then would think old llvm still needs something so your patches would be valuable.
<dcbaker>
that's true
rodrigovivi has joined #dri-devel
<jenatali>
For Vulkan WSI, is there a strongly-specified behavior anywhere for what happens to on-screen contents when a window is resized, but before a new image is presented?
<jekstrand>
jenatali: It's per-window-system, I think, if it's specified at all.
<jenatali>
Mainly directed at jekstrand I guess
<jekstrand>
On X11, it's garbage
<jekstrand>
IDK what the spec says (if anything) about Windows.
<jenatali>
I'll see if I can find anything
<jenatali>
I'd want the behavior to be implicit scaling but I'm not sure I'm going to be able to make that happen. Apparently DComp doesn't do implicit scaling when the window resizes?
<robclark>
jekstrand: only override the bits specified by it.. I suppose there should be some sanity checking to make sure you don't partially overlap so other field or something like that
Peuc_ has joined #dri-devel
<jekstrand>
robclark: So, the correct encoding is to do the default first and then the overrides in opposite order and let them smash stuff?
<robclark>
yeah
sgruszka_ has quit [Remote host closed the connection]
Peuc has quit [Ping timeout: 480 seconds]
<jenatali>
"With Win32, minImageExtent, maxImageExtent, and currentExtent must always equal the window size." which I take to mean that scaling is impossible
<jekstrand>
lol
<jekstrand>
I think scalign means SURFACE_LOST
<jekstrand>
Or INVALID, rather
<jekstrand>
On Android, it can just scale and you can get SUBOPTIMAL
<jekstrand>
But for most I think OUT_OF_DATE is the right thing to do
<jekstrand>
That's the one: OUT_OF_DATE. Not SURFACE_LOST or INVALID. Ignore that nonsense.
<jenatali>
I see, so if I could get scaling to work then I could report SUBOPTIMAL, but if I can't then I just report OUT_OF_DATE
<jenatali>
Easy enough
<jekstrand>
TBH, this might not be the best place to ask about Windows Vulkan WSI behavior. 😅
<jenatali>
I'm more just trying to understand WSI in general
<jenatali>
Thanks though
<emersion>
the first rule of WSI is that you don't ask about WSI :P
<jenatali>
Yeah, I wish I could ignore it but it is a little important
<jekstrand>
Nobody actually needs to SEE their games. Just promise we're rendering correctly somewhere.
<HdkR>
With most TAA implementations there is enough ghosting that you're not seeing the game anyway :P
<Sachiel>
the ultimate horror game
<Sachiel>
black screen all the time, or you can choose to delve into the WSI code to figure out why nothing's showing
<emersion>
oh didn't know many gfx people migrated to mastodon
* emersion
follows a dozen more folks
<jekstrand>
Sachiel: Oh, so you mean all games for at least the first 6 months of Vulkan.
<dcbaker>
karolherbst: did you also run into the need to generate bindings for a system header?
<karolherbst>
dcbaker: yeah
<karolherbst>
but please don't try to deal with that in meson, it won't work
<dcbaker>
how come?
<karolherbst>
things being different one different platforms
<karolherbst>
like stderr is a variable on linux, but a define on BSD
<karolherbst>
and messy stuff like that
<karolherbst>
so not sure how meson could help out with system headers really
dcz_ has quit [Ping timeout: 480 seconds]
<dcbaker>
It will be challenging, though I suspect I'll get to deal with it eventually one way or another :/
<karolherbst>
mhh
<karolherbst>
why though?
<karolherbst>
there is also this problem that you get different definitions
<karolherbst>
like FILE* in a mesa binding is not FILE* in a system binding
<karolherbst>
so things won't compile
Haaninjo has quit [Quit: Ex-Chat]
<dcbaker>
I've learned that in build system land, there is always an obscure but good reason to do something crazy
<dcbaker>
If nothing else when I get back to building crates in meson, there's going to be sys crates that we want to generate bindings to system installed libraries
<dcbaker>
like zlib, for example
<dcbaker>
but I'm also happy to punt on that till I actually need it :)
arisu has quit []
nchery has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<jenatali>
That's embarassing... dzn forgot to hook up instance WSI entrypoints
<danvet>
emersion, debirdify is the tool to help with the swarm migration :-)
<karolherbst>
dcbaker: I'd leave that op to external crates tbh
<emersion>
danvet, but i wasn't on Twitter!
<karolherbst>
the day after tomorrow it will be all over anyway :P
rasterman has joined #dri-devel
junaid has quit [Remote host closed the connection]
<danvet>
emersion, oh
gouchi has joined #dri-devel
<karolherbst>
dcbaker: btw, are you intending of backporting the dependencies feature on bindgen to stable branches?
jkrzyszt has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
<JoshuaAshton>
Feel free to drop fediverse/mastodon names to follow... discoverability is pretty bruh :P
<JoshuaAshton>
or cohost
<JoshuaAshton>
whatever
<karolherbst>
I think we really need our own instance, lol
<karolherbst>
JoshuaAshton: anyway.. probably want to use fedifinder if you got a twitter account and already follow a bunch of us
<mdnavare>
hwentlan_: vsyrjala: On some eDP panels we are seeing the VRR range is 40-105Hz but the mode refresh rate is 360Hz, how do we handle this in the kernel if the mode refresh is outside the VRR refresh rate range
<vsyrjala>
i suspect you are just missing the edid parser fix for >255hz
fab has quit [Quit: fab]
rasterman has quit [Quit: Gettin' stinky!]
bluebugs has joined #dri-devel
gouchi has quit [Ping timeout: 480 seconds]
<jenatali>
jekstrand: I'm sorry for my sins with that WSI change, but it does work and it actually works pretty well
ybogdano has quit [Ping timeout: 480 seconds]
<jekstrand>
jenatali: Which sins are these?
<jekstrand>
And how much penance is Marge going to make you do? 😂
<jenatali>
Eh it's just a bunch of code that's more complicated than I want it to be
<jenatali>
Hopefully none but we'll see...
ahajda_ has joined #dri-devel
epoll has quit [Ping timeout: 480 seconds]
Akari has quit [Ping timeout: 480 seconds]
ahajda has quit [Ping timeout: 480 seconds]
epoll has joined #dri-devel
swick[m] has quit []
swick[m] has joined #dri-devel
gpiccoli has quit [Ping timeout: 480 seconds]
lstrano has quit [Quit: Leaving]
<karolherbst>
ehhh...
<karolherbst>
I figured out why iris regressed...
gpiccoli has joined #dri-devel
<jekstrand>
oh?
apinheiro has joined #dri-devel
<karolherbst>
I launched grids bigger than 65535 on x
<jekstrand>
heh
<karolherbst>
confused why that even worked, because iris only advertises as much
<karolherbst>
or is that more of a "let's stick with 16 bit limits" thing?
<karolherbst>
might as well implement lowering of big grids 🙃 and make use of last_block while at it
<karolherbst>
and here I wanted to actually implemented workgroupinfo stuff because I need it for radeonsi
<karolherbst>
though I suspect we really want to bump it up to 32 bit, because of how crazy CL is
pcercuei has quit [Quit: dodo]
paulk-bis has quit [Ping timeout: 480 seconds]
<karolherbst>
jenatali: how are you actually lowering big grids? bind a new kernel input buffer by updating the offsets or are you placing offsets into special memory?