<karolherbst>
okay.. same problem if I run it again and now two tests fails
<jenatali>
Yeah gimme a minute
<jenatali>
I need to debug mareko's TXQ problem too :)
<karolherbst>
question is rather is the u_printf impl broken or rather my test framework for it...
<jenatali>
[ PASSED ] 138 tests.
<jenatali>
Lovely
<karolherbst>
:)
<karolherbst>
CI uses "MALLOC_PERTURB_=108" though
<jenatali>
I doubt that does anything on Windows
<karolherbst>
run it 1.000.000 times or something? dunno
<jenatali>
Yeah I'm seeing failures
dviola has quit [Quit: WeeChat 3.6]
<karolherbst>
jenatali: it's somehow weird, because there is no way that the last write to that file wasn't a printf... :(
<karolherbst>
but if it's something wrong with my code, why am I not seeing it on linux
<jenatali>
karolherbst: Look at u_memstream_close
<karolherbst>
...
<jenatali>
I think that what happens is the file isn't null-terminated, because why would it be, so the readback ends with a non-null-terminated string
<karolherbst>
yeah...
<karolherbst>
that would actually be a good explenation :)
<karolherbst>
so just insert a \0 and be done with it
<jenatali>
Yeah
<jenatali>
Dunno if it's a guarantee that the Linux memstream impl is always null-terminated?
<jenatali>
But better to be safe and just always insert a null terminator
<karolherbst>
" If a write moves the position to a value larger than the current length, the current length shall be set to this position. In this case a null character for open_memstream() or a null wide character for open_wmemstream() shall be appended to the current buffer."
<jenatali>
Then maybe the fix is just to remove the 'b' from the fopen in the Windows path
<jenatali>
If memstream is supposed to be strings
<karolherbst>
yeah, it is
<karolherbst>
I think...
<jenatali>
Looks like the only existing user on Windows (if you ignore radv and aco) is nir_print
<karolherbst>
glibc says "A null character is written at the end of the buffer. This null character is not included in the size value stored at sizeloc."
<jenatali>
But also it's fixed with a simple fwrite("\0", 1, 1, out); after the u_printf call in the test
<jenatali>
So your choice whether to try to fix the underlying problem or just hack up the test ;)
<karolherbst>
mhh, I think mallocing + 1 byte and writing a 0 byte isn't that difficult :D
jewins has quit [Ping timeout: 480 seconds]
<karolherbst>
open_memstream is kind of a weird aPI...
<karolherbst>
"When the stream is closed with fclose or flushed with fflush, the locations ptr and sizeloc are updated to contain the pointer to the buffer and its size." sounds like fclose/fflush/etc... are bloated so that APIs like open_memstream can even work :)
<karolherbst>
FreeBSD says "A stream'sbuffer always contains a null characterat the end of the buffer that is not included in the current length."
<karolherbst>
so I think it's safe to assume that all libc impls are adding a null character
<jenatali>
Yeah makes some sense for an in-memory stream to do that, but not for a file stream
<karolherbst>
yep
<karolherbst>
anyway, that's a job for "tomorrow" me
cengiz_io has quit [Remote host closed the connection]
ella-0_ has joined #dri-devel
pixelclu- has quit [Ping timeout: 480 seconds]
tlwoerner_ has quit [Ping timeout: 480 seconds]
pixelcluster has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
nchery has quit [Read error: Connection reset by peer]
saurabhg has quit [Ping timeout: 480 seconds]
saurabhg has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
saurabhg has quit [Read error: Connection reset by peer]
oneforall2 has quit [Remote host closed the connection]
lina_ has joined #dri-devel
lina_ has quit []
lina has quit [Quit: leaving]
lina has joined #dri-devel
fab has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
<tjaalton>
dcbaker: hi, I haven't seen mesa version announcements since 22.1.3?
nchery has joined #dri-devel
oneforall2 has joined #dri-devel
fab has quit [Quit: fab]
<dcbaker>
tjaalton: yeah, I’m still in process with todays, and completely forgot the last ones. I’ll have emails out in the morning (pdt)
<tjaalton>
ack, thanks
i-garrison has joined #dri-devel
lemonzest has joined #dri-devel
lkw has joined #dri-devel
kts has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
kts has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
tarceri has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
tzimmermann has joined #dri-devel
kts has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
tursulin has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
srslypascal is now known as Guest7076
srslypascal has joined #dri-devel
Guest7076 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<airlied>
dang marge seems out to lunch
JohnnyonF has joined #dri-devel
fahien has joined #dri-devel
stuart has quit []
MajorBiscuit has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<MrCooper>
airlied: it's because you triggered the pipelines (better to leave rebasing to Marge), you'd need to trigger the manual jobs then
jkrzyszt has joined #dri-devel
mangix_ has joined #dri-devel
mangix has quit [Ping timeout: 480 seconds]
<airlied>
MrCooper: oh wierd I think it was stuck before I triggered them
<airlied>
since there were no other MRs in the way, and it had just failed that one
<MrCooper>
airlied: alternatively, when this happens, re-push with the Part-of: tag removed from the top commit log
<airlied>
I thought I'd dropped them all, but maybe I did pull the marge bits locally
<MrCooper>
well, if the pipeline gets triggered by a non-Marge user, definitely nothing can happen other than Marge waiting for the 1h timeout
* airlied
crosses fingers the other branch I threw in will make it all work out this time!
<MrCooper>
but it sounds like she might have been in a bad state before already
<MrCooper>
nah, she added back the Part-of: tags, looking good
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
frankbinns has joined #dri-devel
frankbinns1 has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
frankbinns has quit [Ping timeout: 480 seconds]
<jani>
tzimmermann: so the conflict in drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c keeps coming back?
pochu_ has quit []
pcercuei has joined #dri-devel
rasterman has joined #dri-devel
mangix_ has quit []
mangix has joined #dri-devel
Major_Biscuit has joined #dri-devel
pochu has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
hansg has joined #dri-devel
Duke`` has joined #dri-devel
mvlad has joined #dri-devel
<tjaalton>
jani: there's a v3 of "HDR aux backlight range calculation" that I'd like to land in some tree when convenient, mind have a look?
mclasen has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<jani>
tjaalton: roger
<tjaalton>
thanks!
tarceri has joined #dri-devel
kts has joined #dri-devel
lkw has quit [Ping timeout: 480 seconds]
<jani>
tjaalton: I think they're fine. I'll just wait for hwentlan_'s reply on what to do with the amd patch.
<tjaalton>
jani: ack
Duke`` has quit []
lkw has joined #dri-devel
<tzimmermann>
jani, possibly. i fixed it twice already
heat has joined #dri-devel
MrCooper has quit [Quit: Leaving]
MrCooper has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
lkw has quit [Ping timeout: 480 seconds]
<jani>
tzimmermann: I saw there was some discussion about git versions wrt merges while I was on vacation. maybe related?
lkw has joined #dri-devel
<MrCooper>
airlied: amdgpu patches should always go to the amd-gfx list as well
kts has joined #dri-devel
fab has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
lkw has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
<tzimmermann>
jani, i don't know.
<tzimmermann>
is there a patch format that works with every version of git
kts has quit []
kts has joined #dri-devel
<tomba>
It's been a while since I worked with atomic states. What's a bridge driver supposed to do with the old bridge-state it gets in atomic_enable()? And where does the driver get the new state? Isn't the new state more relevant?
<tomba>
Is drm_priv_to_bridge_state(bridge->base.state) the new state?
<bl4ckb0ne>
is it possible to blit all layers between 2 layered framebuffer?
<bl4ckb0ne>
spec says that readpixels command always takes the layer zero
<bl4ckb0ne>
but clear command cleans all layers
<jani>
tzimmermann: I guess patch version yeah, but the problem might be related to what kind of merge conflicts you get and how rerere matches with them
lkw has joined #dri-devel
<tzimmermann>
jani, danvet mentioned that ubuntu's version of git (~2.25?) is too old
fahien has quit [Ping timeout: 480 seconds]
lkw has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
aravind has quit []
lkw has joined #dri-devel
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
fahien has joined #dri-devel
<tzimmermann>
airlied, danvet, FYI drm-misc-next-fixes is still empty. so there's no PR this week
kts has quit [Ping timeout: 480 seconds]
<karolherbst>
jenatali: fixed the printf bug, but still having those "D3D12: D3D12GetDebugInterface failed" issues..
<jenatali>
karolherbst: those are unrelated and I should really clean those up at some point
<karolherbst>
I guess those windows fail don't matter for CI?
<jenatali>
Actually those will get cleaned up if one of my MRs gets reviewed and merged
<karolherbst>
huh.. maybe they do
<karolherbst>
ahh
<jenatali>
They're not test failures, no
<karolherbst>
well.. at least the pipeline job fails
<jenatali>
Then there's another failure somewhere
<jenatali>
I'm not in front of a PC yet to take a look
<karolherbst>
"unknown file: error: SEH exception with code 0xc0000005 thrown in the test body."
<karolherbst>
let's see...
jewins has joined #dri-devel
sdutt has joined #dri-devel
<karolherbst>
jenatali: ahh found it
<karolherbst>
jenatali: so we made reordering part of nir_dedup_inline_samplers, but that runs after assigning input/output locations
<karolherbst>
uhm.. input offsets
<karolherbst>
guess I just move it up a bit
<jenatali>
karolherbst: I won't be able to really help for a few hours but that sounds plausible
<karolherbst>
yeah.. I have a patch and see if that fixes it
<karolherbst>
mhhh...
<karolherbst>
another try
<karolherbst>
mhhh
<karolherbst>
maybe the pass is broken...
<karolherbst>
let's see...
<MrCooper>
dcbaker: looks like the 22.1.4 & .5 release notes are missing from docs/relnotes/ on the main branch, and consequently from the website
<karolherbst>
jenatali: yeah.. no idea.. I tried to move the pass where I think it makes sense, but seems like I am not able to fix it from here :(
hansg has quit [Remote host closed the connection]
mbrost has joined #dri-devel
lkw has quit [Ping timeout: 480 seconds]
lkw has joined #dri-devel
<jekstrand>
In a VM with a GPU that's been made accessible via PCI pass-through, how do host allocations work?
bcheng_ has quit [Remote host closed the connection]
<jani>
tzimmermann: does dim rebuild-tip work for you? fails for me
bcheng has joined #dri-devel
<MrCooper>
jekstrand: to me, PCI passthrough would imply that the host cannot use the GPU at all
<jekstrand>
MrCooper: Yes, that's correct
<MrCooper>
what do you mean by "host allocations" then?
<jenatali>
jekstrand: "host" == host OS, or "host" == system RAM i.e. not device?
<jekstrand>
jenatali: I mean system RAM but inside the guest OS.
<jekstrand>
The GPU can't be getting actual physical addresses becasue that'd be a security nightmare
<jekstrand>
So the host has to be involved somehow
<jenatali>
I could speculate but I think I don't know enough in that space to actually be helpful :)
<jekstrand>
jenatali: Fair. :)
<jekstrand>
Unfortunately, neither danvet or airlied are around right now. I was hoping someone might know.
<jenatali>
My knowledge of virtualization is pretty much limited to paravirtualization or remoting techs, not so much PCI-level stuff :(
<jekstrand>
:-/
zehortigoza has quit [Remote host closed the connection]
<MrCooper>
my guess would have been IOMMU, a quick web search seems to support that
<tzimmermann>
jani, it looks like some tree has been updated and now conflicts with the patch i added a few days ago
lkw has quit [Ping timeout: 480 seconds]
elongbug has joined #dri-devel
elongbug has quit []
<tzimmermann>
i'll try to fix it
<karolherbst>
jekstrand: yeah, for passthrough you _require_ an IOMMU
<karolherbst>
and you need CPU extensions, like on intel it's Vt-d
<karolherbst>
which implies having an IOMMU
<tzimmermann>
jani, i pushed a new drm-tip. it could be that our amdgpu bug is back
lkw has joined #dri-devel
<karolherbst>
well technically it's part of the actual mainboard chipset
<tzimmermann>
jani, but the diff for the relevant files between drm-tip and drm-misc-next is empty. so drm-tip should be building
<tzimmermann>
fingers crossed
nehsou^ has quit [Ping timeout: 480 seconds]
<tzimmermann>
jani, i just built drm-tip successfully
sdutt has quit []
sdutt has joined #dri-devel
<jekstrand>
karolherbst: Ok, I figured. So it's a VM client allocation that gets passed through the IOMMU?
<dolphin>
jekstrand: the VM programs intermediate addresses to the page tables of the GPU
<dolphin>
they are translated by IOMMU unit to physical memory addresses
<jekstrand>
dolphin: What do you mean by "intermediate addresses"? Is that the same as the userspace address of the qemu instance or whatever?
<dolphin>
well, there is a second set of page tables for the IOMMU
<dolphin>
and those are managed by the hypervisor/host kernel
<jekstrand>
Right
<jani>
tzimmermann: dim rebuild-tip fails for me :(
<jani>
git version 2.30.2
<jekstrand>
dolphin: Assuming qemu for as second but it could be anything.
<dolphin>
so, if the guest VM tries to access "out of bounds physical page", all it gets is IOMMU page fault
<dolphin>
well yeah, qemu is just an UI to the kernel functions that do this
<jekstrand>
dolphin: So the userspace qemu instance allocates some memory (maybe MAP_POPULATE?) and then pass that off to its kernel driver to set up the IOMMU?
<dolphin>
if you are using KVM acceleration in qemu, I suppose
<jekstrand>
Ok, there's a lot of KVM details in here but I think I get the rough shape.
<dolphin>
pretty much so, except it's more complex than that as there is ballooning etc.
<dolphin>
but it's mostly not related to the GPU operation at all
<jekstrand>
Sure
<dolphin>
the GPU sees addresses, those are handled by the IOMMU unit before it actually lets the device access anything
<jekstrand>
Right
<dolphin>
(this is also the short story why iGPU IOMMU is painful, they actually have a separate IOMMU unit for the iGPU)
<jekstrand>
So the VM client just needs to set up an IOMMU mapping from whatever memory it has to addresses that the GPU can see and then it sets up the GPU page table to point at those IOMMU addresses.
<dolphin>
yep
<jekstrand>
Cool. That makes sense.
<dolphin>
the VM kernel driver doesn't have to know if VT-d or native is used
<dolphin>
(if it weren't for the HW bugs...)
<jekstrand>
heh
<sravn>
tzimmermann: Thanks for the write-up on the openchrome driver, I hope we will see a slimmed down driver in the next version.
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
eletrotupi has quit [Remote host closed the connection]
eletrotupi has joined #dri-devel
bmodem has joined #dri-devel
eletrotupi_ has joined #dri-devel
bmodem has quit []
kts has joined #dri-devel
zehortigoza has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
<karolherbst>
jenatali: I suspect that inline samplers need to be the last variables, not just the last samplers?
<jenatali>
Sounds plausible
<karolherbst>
mhhh
<jenatali>
That's probably fixable. Haven't gotten there yet but it's on my to-do list for this morning
<karolherbst>
even though I assign storage to samplers, it doesn't relaly matter where they are
<karolherbst>
guess having them in the end makes it easier to deal with their storage... or maybe it's enough to make them 0 sized.. mhh
<karolherbst>
anyway.. I just want inline samplers to be the last ones
<jenatali>
Yeah that's probably fine for me too
<karolherbst>
okay, cool
<jenatali>
The code just probably has an assumption that needs to be relaxed. But I'll confirm once I can take a closer look
<karolherbst>
cool.. anyway, that's like the only difference I can make of compared to the old code
<jenatali>
daniels: I'm looking through emails from while I was out and noticed that piglit!710 looks to be good to land... any reason not to merge it?
<daniels>
jenatali: nope, was just seeing if anyone else wanted to review. that and, tbqh, had completely forgotten about it
<jenatali>
Makes sense :)
Major_Biscuit has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
lkw has quit [Ping timeout: 480 seconds]
lkw has joined #dri-devel
frieder has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
jfalempe_ has quit []
<dcbaker>
MrCooper: yup, I ran out of time last night, so I'm getting to it now
eletrotupi has quit [Remote host closed the connection]
<jenatali>
This is a new one... "Gitlab refused to merge this request and I don't know why!"
<airlied>
jekstrand: yeah iommu does the msgic as indicated
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
frieder has quit [Remote host closed the connection]
rasterman has joined #dri-devel
frankbinns1 has quit [Remote host closed the connection]
<anholt>
has anyone made "piglit drawoverhead, but for vulkan"?
fab has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
Duke`` has quit [Read error: Connection reset by peer]
fab has quit [Quit: fab]
<airlied>
anholt: I've done zink drawoverhead on radv :-P
<anholt>
airlied: that's what I'm doing
<jenatali>
karolherbst: I hit a crash in nir_dedup_inline_samplers, in the nir_foreach_uniform_variable loop header
<anholt>
but there's a lot of GL overhead with tc and whatnot that obscures the vulkan behavior.
<jenatali>
karolherbst: Loop needs to be _safe
<airlied>
anholt: haven't seen anything else like it, at least for vulkan it would mostly be for cmd buffer recording overheads, and those can in theory be threaded at least
<airlied>
but I've fixed a bunch of cmd buffer overheads in radv/zink with perf tracing on some benchmarks
<jekstrand>
I had a Google person throw a benchmark at me a few years ago.
<jekstrand>
I don't remember who or what
<anholt>
I do really want to isolate stuff like "how expensive is it to change one descriptor?" and "how expensive is it to change the pipeline?"
<jenatali>
karolherbst: Pushed your fixup patch
<airlied>
anholt: it's vulkan you can thread it so it doesn't matter? :-P
<airlied>
but yeah a vk drawoverhead would probably be useful
<jenatali>
anholt: There was a 3DMark API overhead benchmark back when DX12 and Vulkan were first released
<airlied>
just time cmd buffer recording
<jenatali>
It's not piglit but it's something
<anholt>
airlied: I'm also concerned with how fast the gpu can chew through my excessive command stream.
ybogdano has quit [Read error: Connection reset by peer]
<anholt>
(with tilers, there's more pressure on cmd stream since you run through it more times)
<anholt>
and qc's command stream is... verbose.
<karolherbst>
jenatali: ahhh, good catch
<anholt>
jenatali: hmm, maybe I should dig up 3dmark. I've got gfxbench, but it's got very limited vulkan testing.
<karolherbst>
with that I think I can finally land that MR :)
Major_Biscuit has quit [Remote host closed the connection]
Major_Biscuit has joined #dri-devel
Major_Biscuit has quit [Read error: Connection reset by peer]
Major_Biscuit has joined #dri-devel
<karolherbst>
totally unrelated question: how would a rust version of gallium be called? asking for a friend
<karolherbst>
dcbaker: btw, I think there is a bug in meson in combination with add_languages. So if I use add_languages to add rust, but have a 'rust_std=2021' entry inside project.default_options, the default option is never pickd up
<karolherbst>
or maybe gets lost on reconfigure or something..
digetx has quit [Ping timeout: 480 seconds]
<dcbaker>
that sounds like a bug
<karolherbst>
point is... the default option isn't applied in some cases
<dcbaker>
also, for your friend, "oxide"
<karolherbst>
:D
<karolherbst>
anyway.. maybe I try to create a small reproduce and open a PR with it
<dcbaker>
that sounds completely fixable, probably add_language is skipping some codepath that isn't skipped initially
<karolherbst>
yeah.. something
<karolherbst>
could also be that it only happens _if_ rust is added on reconfigure and not the initial configure
<karolherbst>
something something
gouchi has quit [Quit: Quitte]
<dcbaker>
that... I would believe that. and that would be more annoying to fix
<airlied>
karolherbst: which bits of gallium :-)
nchery has quit [Read error: Connection reset by peer]
<karolherbst>
airlied: all of them of course! :P
nchery has joined #dri-devel
<airlied>
rust drivers! start with zink :-P
<karolherbst>
hehe
<karolherbst>
though not sure if we want to create our own vulkan wrapper
<karolherbst>
or just get cargo support ready
digetx has joined #dri-devel
<zmike>
I've always thought ntv would be a natural thing to rust-up at some point
Major_Biscuit has quit [Ping timeout: 480 seconds]
<airlied>
dcbaker: for a 22.1 MR do I go against staging/22.1 or 22.1?
<dcbaker>
staging please
<airlied>
dcbaker: fyi staging isn't aligned with 22.1 at the moment
<karolherbst>
zmike: ntv?
<airlied>
but I've filed 17889, and should resolve once you realign things
<airlied>
karolherbst: nir to spirv
<karolherbst>
ahh
<dcbaker>
airlied: fixed :)
sul has quit []
sul has joined #dri-devel
<karolherbst>
yeah.. not sure what's the best approach to keep this going. I don't think the gallium wrapper I've come up in Rusticl is particular useful for other use cases atm, but maybe if more code would make use of gallium and is written in rust we could come up with something nice in the future.. dunno
<karolherbst>
but that also depends on what others think is fun to work on anyway :)
ybogdano has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
q66_ is now known as q66
eukara has joined #dri-devel
<HdkR>
Has anyone run Magicka 2 and noticed their FXAA shader doesn't compile with Mesa?
ybogdano has joined #dri-devel
<HdkR>
Complains about macro names with __ being reserved, then syntax error
<HdkR>
The game's debug output doesn't show the fulll FXAA 3.11 source so it's a pain to track the line error
<HdkR>
I sould say, doesn't compiler with Freedreno's stack anyway :P
gawin has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
pcercuei has quit [Quit: dodo]
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
<karolherbst>
dcbaker: yeah, so it indeed only happens if adding rust is hidden behind an option and that option was initially set to not add_language('rust')
<karolherbst>
I suspect projects using C++ optionally might run into the same issue