ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
nchery has joined #dri-devel
<karolherbst>
jekstrand: what's the req for i915 userptr to suceed creating one?
<karolherbst>
ptr aligned to size?
illwieckz__ has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
illwieckz__ has joined #dri-devel
tzimmermann_ has joined #dri-devel
<jekstrand>
karolherbst: ptr aligned to PAGE_SIZE, I think.
<karolherbst>
seems about right
<karolherbst>
but anyway.. something is not right
<karolherbst>
jekstrand: so when I create a resource for the printf buffer, do a clear_buffer on it and map it later with MAP_READ_WRITE it contains garbage
<jekstrand>
karolherbst: It's entirely possible I messed up clear_buffer
<karolherbst>
yeah.. thing is.. the clear buffer CL CTS tests are fine with it
<karolherbst>
they just fail because of resource_from_user failing
<karolherbst>
well.. partly
<karolherbst>
everything else is okay
macc24_ has joined #dri-devel
<karolherbst>
mhh but without clear_buffer it's all 0
tzimmermann has quit [Ping timeout: 480 seconds]
macc24 has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: although it looks more like a sync issue
<karolherbst>
sometimes a chunk at the start is 0
<karolherbst>
and it kind of varies in size
<karolherbst>
but not sure why there are undefined values
rasterman has quit [Quit: Gettin' stinky!]
<jekstrand>
karolherbst: IDK. I may have messed it up. That's what I'm betting on. (-: It's basically untested.
<jekstrand>
karolherbst: I've not figured out a good strategy for > 16B patterns yet.
<jekstrand>
It can be done, it's just annoying.
<karolherbst>
it's literally just 0
<jekstrand>
well, sure.
<jekstrand>
Just warning you that there are CTS tests that will crash with it.
<karolherbst>
ohh sure
<karolherbst>
but there is a reason I am testing it with iris, because with llvmpipe the buffer contains weirdo values as well
<jekstrand>
I tried to tie it into iris' cache tracking but I don't really know how it all works.
<jekstrand>
So there could easily be a sync issue, especially since you're switching between 3D for the clear and compute for the kernel.
<karolherbst>
but the issue with llvmpipe is something else
<jekstrand>
karolherbst: Oh, well in that case... -ENOTTHEONLYONEWITHTHEBUG
<karolherbst>
the issue isn't really in clearing
iive has quit []
<karolherbst>
if I don't clear, it's all 0
<karolherbst>
I just clear because... I think it's the right thing or so? dunno how to init a buffer with 0s the correct way :)
<jekstrand>
So the clear is filling it with garbage?
<karolherbst>
anyway
<karolherbst>
yeah
<karolherbst>
on iris
<jekstrand>
weird...
<karolherbst>
on lp that clear seems to do the correct thing
<karolherbst>
what annoys me that this buffer_map doesn't work as expected either :/
<karolherbst>
jekstrand: also... gcc complains about something :D
<karolherbst>
as I rebased on main and stuff
<jekstrand>
karolherbst: What's with this NIR warning about variable modes?
<karolherbst>
maybe I just suck it up and revert that change locally and deal with whatever bindgen throws at me, even if that's sometimes annoying
<karolherbst>
I changed it to the enum
<karolherbst>
instead unsigned
<jekstrand>
Oh
<karolherbst>
yeah...
<karolherbst>
we have that _all thing which needs 16 bits
<karolherbst>
ehh or _last?
<karolherbst>
nir_num_variable_modes = 16,
<karolherbst>
ehh wait
<karolherbst>
that's not out of range
<karolherbst>
nir_var_mem_global = (1 << 15), ?
<karolherbst>
nope..
<karolherbst>
heh weird
<karolherbst>
ehh no
<karolherbst>
that's 16
<karolherbst>
jekstrand: guess that warning is real then
<karolherbst>
ohhhhhh
<karolherbst>
jekstrand: maybe that busted something ...
<karolherbst>
oh well
<karolherbst>
dunno
<jekstrand>
karolherbst: Here you go
<jekstrand>
for (unsigned i = 0; i < bs; i += data_size)
<jekstrand>
uint8_t data_repeated[16];
<jekstrand>
- memcpy(data_repeated + i, data + i, data_size);
<jekstrand>
+ memcpy(data_repeated + i, data, data_size);
<jekstrand>
In blorp_blit.c
<karolherbst>
:D
<karolherbst>
cool
<mattst88>
lol, oops
<karolherbst>
jekstrand: okay.. cool, that fixes that clearing, but not my "map buffer after launch_grid" problem :(
<karolherbst>
and I am literally doing the same as clover?
<jekstrand>
karolherbst: I can try to look into some of this on Monday. Not going to debug cache flushing and/or sync issues at 8:00 PM on a Friday.
<karolherbst>
well.. it also happens with llvmpipe
<karolherbst>
though there I just get trashy values
<jekstrand>
Ok, so maybe we have one bug between the two of them.
<karolherbst>
not sure...
<karolherbst>
normally I use fences between CL events and that all works, but in this case I don't.. maybe I forget something so drivers sync properly? dunno
<karolherbst>
but even before using fences llvmpipe usually didn't care about any of this
<karolherbst>
I am sure it's my fault somewhere
* karolherbst
should go to bed
<karolherbst>
jekstrand: ohh no... I think I found it
<karolherbst>
I just do the lowering wrong
<karolherbst>
ahh yeah...
<karolherbst>
I have to prefill it with something meaningful
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
mhenning has quit [Quit: mhenning]
idr has quit [Quit: Leaving]
columbarius has joined #dri-devel
paulk1 has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
co1umbarius has quit [Ping timeout: 480 seconds]
paulk has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.4]
macc24 has joined #dri-devel
anarsoul has quit [Read error: Connection reset by peer]
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
<DanaG>
I'm having some interesting adventures in a machine that has an ASPEED BMC and a Radeon Pro WX 4100. If I boot with only the ASPEED (what a name for such a slow device), GDM won't draw on it, and I think I can't even log in. If I attach a monitor, and log in to KDE with sddm, I can log in to an X session, but kwin-wayland crashes every time in gbm_dri_bo_import.
<DanaG>
I'm guessing things are quite unhappy with the fact that the AST is missing some feature or other. With X, it doesn't appear to have any xrandr offload capabilities. Can't be a sink.
kts has quit [Quit: Konversation terminated!]
DanaG has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
DanaG has joined #dri-devel
Duke`` has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
<DanaG>
Actually, gnome-shell crashes in the same function, gbm_dri_bo_import (though with a different stack above it).
<karolherbst>
for a long time I got "arg_1" as the format string and I was like: what am I doing wrong and at some point I started to see memory corruptions ...
kts_ has joined #dri-devel
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
mhenning has joined #dri-devel
<alyssa>
oops, accidentally implemented fmul.rtz
<karolherbst>
alyssa: yay
<alyssa>
karolherbst: yay what
<karolherbst>
alyssa: well you know what's fmul.rtz now :p
<alyssa>
karolherbst: ah well yes
<karolherbst>
dcbaker: ehh.. we really need external crate support :( even regex is not part of core rust
<dcbaker>
Yeah, I have a branch that can make some basic things work, I’m just trying to sort out additive features for diamonds dependencies and the rest is just writing code
<karolherbst>
dcbaker: you know what I need to pass to rustc in order to use something from the registry? fedora does have packages for some crates and they live in /usr/share/cargo/registry/
<alyssa>
...why does mesa need regex
<karolherbst>
alyssa: printf in CL ...
<alyssa>
hm
<karolherbst>
yeah...
<karolherbst>
makes parsing the string easier
<karolherbst>
I could do probably without it, but...
<dcbaker>
That’s a good question
<dcbaker>
And one I want to know the answer to
Haaninjo has joined #dri-devel
<alyssa>
obviously the answer is to FFI the posix regex functions /s
<karolherbst>
uhh
<kchibisov>
karolherbst: when building resulted lib: rustc --extern regex=regex-youve-built.rmeta.
<karolherbst>
ehh right.. I also need to build extern crates
<kchibisov>
And when building regex 'rustc --crate-name regex /regesitry/path/to/regex/lib.rs --crate-type lib --emit=dep-info,metadata,link
<kchibisov>
You could look at 'cargo build -v' from some crate to get inspiration.
<kchibisov>
karolherbst: do you have cargo or you must use plain rustc?
<karolherbst>
plain rustc
gouchi has joined #dri-devel
<karolherbst>
I mean I could probably call cargo to make stuff easier, but in the end I end up with rustc
<kchibisov>
That's a bit more involved than, since you can built deps from local registry with cargo, put in dir you've specified, and invoke rustc in the end.
<karolherbst>
alyssa: just need to figure out those 12 flags
<karolherbst>
but we do have weirdo flags on fmul and fadd as well
<alyssa>
no i mean the internal operation of fadd is nontrivial
<karolherbst>
but we are lucky, new hw doesn't have fadd or fmul
<karolherbst>
alyssa: ?
<karolherbst>
ehh wait.. we still have FADD we don't have IADD
<karolherbst>
and also still have FMUL, but no IMUL
<karolherbst>
alyssa: I mean, call me optimistic, but my impression is that you encode an fadd and it does the right thing, no?
<alyssa>
complicated for the hardware
<alyssa>
look at float64.glsl for example
<karolherbst>
that's because it uses int math
rasterman has joined #dri-devel
<karolherbst>
32 bit even
ella-0 has joined #dri-devel
<alyssa>
i think we might be talking past each other
<karolherbst>
probably
<dcbaker>
karolherbst: there’s an old branch that does not apply to master that might work. My current branch I can push and simple crates work, but I don’t think nested creates work yet
<karolherbst>
ahh
<dcbaker>
There’s some deep Meson implantation details I’m trying to work around
<dcbaker>
When I’m not on my phone I’ll run some id then by you, you probably can help answer some of the user experience questions I’ll have
<karolherbst>
sounds good
Simonx22 has joined #dri-devel
<dcbaker>
karolherbst: So here's what I'm trying to figure out (basically how much backbending do I need to do here). Meson is a greedy interpreter, so it evaluates everything as soon as it finds it, and then ignores any alternative paths. Rust subprojects have a bit of a mismatch here in that they expect to be able to pass options down to other subprojects, (I'm equating meson options with cargo features)
<dcbaker>
and it does dedup, so if A wants C, and B wants C, and B wants C feature 1, and A wants feature 2, then cargo will build one copy of C with 1 and 2. Which is what meson wants to do too
<dcbaker>
for a single subproject call that's relatively easy
<dcbaker>
but, the question is, how likely is it that we're going to want to call multiple rust crates as subprojects from within meson?
<karolherbst>
dcbaker: are you planning on invoking cargo to build deps or do you want to do everything in meson?
<dcbaker>
everything inside meson, no cargo dependency at all
<dcbaker>
just rustc or gcc-rs
<karolherbst>
okay
<karolherbst>
I think it will be very likely that we will have multiple rust crates
<dcbaker>
So the question is, are you giong to want to do something like `library('foo', 'lib.rs', rust.cargo('A'), rust.cargo('B'))`?
<karolherbst>
I probably already looked at 10 that I would like to use most likely, but worked around it by implementing stuff myself or not caring atm
Lyude has quit [Quit: WeeChat 3.4]
<karolherbst>
dcbaker: yeah, I guess. Rust seems to rely on crates anyway. So even "basic" features like regex are in crates and the official docs even recommend using certain crates for certain things
<karolherbst>
using rust without crates is kind of painful
<dcbaker>
yeah, and I have something that mostly works, but there are some design issues that are pretty impossible to solve without rewriting
<dcbaker>
namely that it greedily invokes sub-sub projects
<dcbaker>
so you end up having to build two copies of C in the case I had above
<dcbaker>
which we really don't want to do
Lyude has joined #dri-devel
<karolherbst>
yeah.. I can see that this could lead to huge sub project trees as well
<dcbaker>
and Jussi would never let it land, lol
<karolherbst>
well couldn't meson reuse subprojects internally?
<karolherbst>
like all deps will be registered and free to reuse by anything
<dcbaker>
It does, actually, by default
<karolherbst>
ahh
<dcbaker>
which means that when we build C we need to have all of the features the entire project needs
<karolherbst>
aren't some features even mutually exclusive?
<dcbaker>
they can be, though cargo's official solutoin is "error at build time"
<karolherbst>
mhh
<karolherbst>
okay so if deps require incompatible features from a dep it errors?
<dcbaker>
and features are supposed to be additive, so you're not supposed to have "negative features" ie, use `std` not `no_std`
<dcbaker>
and just make `std` a default option
<karolherbst>
okay
<karolherbst>
so meson needs to collect which features of which extern crate is required before building things?
<dcbaker>
yes, exactly
<dcbaker>
which isn't super hard for a single call of `rust.cargo`, we just parse the toml into our internal data structures, then propogate options, and build
<dcbaker>
but when you have two calls to `rust.cargo` that can affect each other, that's where the fun starts
<karolherbst>
ahh
<karolherbst>
couldn't you just modify the subproject created from either call?
<karolherbst>
and like add features to it?
<dcbaker>
but turning on a feature in a crate can turn on other features
<karolherbst>
and have it even a method on cargo crates as a special subprojects or something?
<dcbaker>
like, adding the `regex` feature could add a dependency on the `regex` crate
<karolherbst>
like crate.add_feature(...) because sometimes it might depend on project options as well
<dcbaker>
meson tries really hard to have objects be immutable after creation
<dcbaker>
there are a few exceptions, but most objects can't be modified once created
<karolherbst>
yeah sure.. but I don't think this would work out here
<dcbaker>
at least at the DSL level
<karolherbst>
I would expect that I can add more features to a crate later on
<karolherbst>
otherwise I'd have to collect all of that first.. mhh
<karolherbst>
well maybe that's people are supposed to do
<dcbaker>
My current thinking is to hide this at the DSL level by creating internal "promise" objects, and then evaluating all cargo subprojcts at the end of the configure step and replacing the promises
<karolherbst>
yeah.. maybe
<karolherbst>
but internally it needs to be mutable
<dcbaker>
but at the DSL level you'll get what still looks exactly like you would expect, a dependency with normal dependency methods
<dcbaker>
sure, and internally everything is mutable
<dcbaker>
terribly so :/
<dcbaker>
alrady
<dcbaker>
the only really tricky thing to solve (I think) is what to do about the `.found()` method of dependency, because you could run into issues with that
* dcbaker
really wishes meson++ was more mature, since it uses an SSA IR this would be sooo much easier
<karolherbst>
mhhh
<dcbaker>
okay, so I think I have the answer to my question, and lots of fun ahead of me
<karolherbst>
that found thing really sounds annoying to solve
<karolherbst>
maybe ignore features?
<karolherbst>
I expect that features _might_ get removed and that might need special handling anyway
<karolherbst>
the DSL version could have its own list of features it requires (excluding ones added from other crates dependencies) and found just checks those?
<dcbaker>
that's a possibility
<karolherbst>
and everythign else will get resolved internally
<dcbaker>
I guess we could ignore default features... and just let you specify them int the default_options like we do for meson subprojects...
<karolherbst>
I think that makes more sense from a dev pov anyway. the crate I care with the features I care about are either there or not
<karolherbst>
but if another crate needs the same one but features are missing, I wouldn't mind if found on the former one is true
<karolherbst>
because I only care if I can use the second crate or not
<dcbaker>
I guess we can write it like that to start with and see where that gets us
<karolherbst>
yeah
<dcbaker>
it would be a lot less work, lol
<karolherbst>
I think it's totally enough
<karolherbst>
why should found return true if some other crate needs a feature which isn't there
<karolherbst>
ehh false
<karolherbst>
yeah.. and I think default features aren't really important
<karolherbst>
you should be explicit about those things anyway
<karolherbst>
although would be annoying if you'd have to write 'std' on every one
alyssa has quit [Quit: leaving]
<dcbaker>
I think we can make some of that less painful with meson's `yielding` options, which means you could add a `std` option to mesa, and all of the crates would inherit that
<karolherbst>
dcbaker: what's the problem with adding default features though?
<dcbaker>
default-features are easy to handle
<dcbaker>
it's the propogation and combination of features that's difficult
<karolherbst>
ohh, mhh
<karolherbst>
work on every extern crate thing until nothing changes anymore? dunno :D
<dcbaker>
that's basically my plan, lol
<karolherbst>
although I don't think it should be too hard to solve. Adding a feature might trigger new deps to be added, so I'd implement something like crate.enable_features(...) which would add more deps or call enable_features on existing deps and all would work out recursively or so? dunno
<dcbaker>
the biggest challenge is that the way this works it that it parses the TOML, and then generates meson AST from that TOML. I don't want to be modifying that AST, because that's just not fun
RSpliet has quit [Ping timeout: 480 seconds]
<dcbaker>
so I think I'm going to have to go with the "promise" idea
<karolherbst>
yeah.. probably
<dcbaker>
not the end of the world, just means lots of tests
<karolherbst>
it's a complicated feature after all
<dcbaker>
yeah, but hopefully useful
* dcbaker
should work really hard on this, then pitch it as a talk at rustconf, which is going to be near me this year...
<karolherbst>
yeah
RSpliet has joined #dri-devel
illwieckz has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
luckyxxl has quit [Quit: bye]
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
gouchi has quit [Remote host closed the connection]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
heat has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
DanaG has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
ds` has quit [Quit: ...]
ds` has joined #dri-devel
dllud_ has quit [Remote host closed the connection]
dllud has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
danvet has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]