JohnnyonFlame has quit [Read error: Connection reset by peer]
Company has quit [Remote host closed the connection]
sima has joined #dri-devel
itoral has joined #dri-devel
bgs has joined #dri-devel
vliaskov has joined #dri-devel
Guest8136 has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
vliaskov_ has joined #dri-devel
bgs has quit [Remote host closed the connection]
vliaskov has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
<zzxyb[m]>
may I ask how to enable driver_debug, I failed to set GALLIUM_DDEBUG=always
<zzxyb[m]>
zzxyb[m]: gallium driver_ddebug
Zopolis4 has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
f11f12 has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #dri-devel
vliaskov__ has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
bmodem has joined #dri-devel
tursulin has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
Duke`` has joined #dri-devel
jfalempe has joined #dri-devel
mvlad has joined #dri-devel
pcercuei has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
bmodem has quit [Remote host closed the connection]
bmodem has joined #dri-devel
ahajda has joined #dri-devel
MajorBiscuit has joined #dri-devel
MajorBiscuit has quit []
MajorBiscuit has joined #dri-devel
Ahuj has joined #dri-devel
RAOF has left #dri-devel [#dri-devel]
Guest7959 is now known as go4godvin
Zopolis4 has quit [Quit: Connection closed for inactivity]
rasterman has joined #dri-devel
swalker__ has joined #dri-devel
donaldrobson has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
thellstrom has joined #dri-devel
hikiko has joined #dri-devel
swalker__ is now known as sarahwalker
<sarahwalker>
I'm looking at a corruption issue in a map_wc shmem buffer, and I see the comment in the shmem get_pages function - "TODO: Allocating WC pages which are correctly flushed is only supported on x86."
<sarahwalker>
Does this mean I should expect the map_wc functionality to not work on arm64?
frankbinns has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
tristan has joined #dri-devel
tristan is now known as Guest8165
Guest8165 has quit [Ping timeout: 480 seconds]
tyalie has quit [Quit: Ping timeout (120 seconds)]
tyalie has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
robmur01 has quit [Remote host closed the connection]
ahajda_ has joined #dri-devel
dviola has quit [Quit: WeeChat 4.0.2]
robmur01 has joined #dri-devel
ahajda has quit [Ping timeout: 480 seconds]
ahajda_ is now known as ahajda
<bbrezillon>
sarahwalker: Unless I'm wrong, 'write-combined' is just 'uncached' on arm64 (robmur01 to confirm that), so it should work just fine without any CPU-side cache maintenance operations. This being said, you might be in trouble if your system is coherent, and you map things uncached. I remember hitting this problem with panfrost on some MTK SoC.
<mripard>
we had a discussion recently for longsoon iirc about this
<HdkR>
Oh hey, I remember reading that comment when I was poking at why latest generation Radeons don't work on Solidrun boards
<mripard>
and my understanding was that dma_alloc_wc semantics are that it allocates a DMA coherent buffer with WC attributes, so the assumption is that you cannot have any coherency issue
<mripard>
I think the issue with longsoon was that the system (or device, I can't remember) was defined as coherent because it had an IO-coherency unit, but it didn't operate on the WC write buffer
ahajda has quit [Read error: Connection reset by peer]
tristan has joined #dri-devel
ahajda has joined #dri-devel
tristan is now known as gtristan
<mripard>
If you're in the same situation, then I guess it all boils down to whether the device can be considered coherent in such a case :)
pa has joined #dri-devel
<bbrezillon>
mripard: it's a buffer allocated through shmem, so no dma_alloc_wc() taking care of the coherency prop to pick the right attributes AFAICT.
<mripard>
oh, right
<bbrezillon>
sarahwalker: I guess it's worth trying to force map_wc=false, just to see if that solves the problem
pa| has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
Ahuj has quit [Ping timeout: 480 seconds]
ohmaddd^ has joined #dri-devel
dviola has joined #dri-devel
gtristan has quit [Ping timeout: 480 seconds]
f11f12 has quit [Quit: Leaving]
itoral has quit [Remote host closed the connection]
<zmike>
eric_engestrom: I'm gonna do an extra vvl version bump since I gotta rebuild the containers again anyway
<zmike>
I'll assume you're okay with that as long as it passes ci
donaldrobson_ has joined #dri-devel
donaldrobson has quit [Ping timeout: 480 seconds]
gtristan has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
sarnex has quit [Read error: No route to host]
sarnex has joined #dri-devel
Haaninjo has joined #dri-devel
yuq825 has quit []
mvchtz has quit [Quit: WeeChat 3.5]
mvchtz has joined #dri-devel
kzd has joined #dri-devel
junaid has joined #dri-devel
Cyrinux9474 has quit []
Cyrinux9474 has joined #dri-devel
kts has joined #dri-devel
<robmur01>
bbrezillon, sarahwalker: yup, from what I remember of hooking up Panfrost's coherency support, map_wc only means that the BO pages get a non-cacheable mapping to userspace - any touching of them from the kernel side still needs the appropriate DMA API business which you probably need to worry about getting right if you're doing anything cleverer than delegating everything to the helper libraries
<eric_engestrom>
zmike: yeah, I just checked the new rev, it's still just a bump of the version number and the appropriate image tags, so it all lgtm
donaldrobson_ has quit [Ping timeout: 480 seconds]
donaldrobson has joined #dri-devel
aravind has joined #dri-devel
Company has joined #dri-devel
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
ahajda has joined #dri-devel
ohmaddd^ has quit [Remote host closed the connection]
ahajda_ has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
ahajda__ has joined #dri-devel
jessica_24 has joined #dri-devel
ahajda has quit [Ping timeout: 480 seconds]
ahajda__ is now known as ahajda
kts has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
ahajda_ has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
agd5f_ has quit []
ahajda_ has joined #dri-devel
agd5f has joined #dri-devel
pzanoni has joined #dri-devel
ahajda__ has joined #dri-devel
ahajda has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
ahajda_ has quit [Ping timeout: 480 seconds]
ahajda__ has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
djbw has joined #dri-devel
heat_ has joined #dri-devel
bmodem has joined #dri-devel
illwieckz has joined #dri-devel
bcheng has quit [Remote host closed the connection]
bcheng has joined #dri-devel
MajorBiscuit has quit [Quit: WeeChat 3.6]
<eric_engestrom>
gfxstrand, karolherbst: `meson test` no longer passes now that NVK has been merged; `mme_builder` seems to take forever to run (143sec on my machine, way above the default 30sec timeout, making it fail)
<karolherbst>
uhhh....
<karolherbst>
is that on a nouveau machine?
<eric_engestrom>
nope
<eric_engestrom>
(m2 air)
<karolherbst>
that mme stuff shouldn't run on anything not being nouveau :D
<karolherbst>
well.. some of it at least
<eric_engestrom>
ack
<eric_engestrom>
I guess the test needs to detect that and exit with 77
<karolherbst>
there are two parts: unit tests and making sure the simulator agrees with the hardware
<eric_engestrom>
(77 = "this test was skipped")
<zmike>
...are we debating how to make MEME_BUILDER pass?
<karolherbst>
eric_engestrom: do you have a log?
<gfxstrand>
The mme builder tests shouldn't need hardware
<gfxstrand>
The only one that runs as part of `meson test` should be the one that is simulator-only.
<eric_engestrom>
karolherbst: I have the test output if that's what you mean; they all take 0ms except "mme_builder_test.while_ine (143424 ms)"
<karolherbst>
mhhhhhh
<karolherbst>
maybe the simulator is buggy on arm
<eric_engestrom>
I've also reproduced it on an x86 machine, so I'm not sure it's arm-specific
<karolherbst>
mhh funky
<eric_engestrom>
(or non-intel specific, I mean)
<karolherbst>
maybe some weird undefined behavior happening somehwere
sarahwalker has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<karolherbst>
well.. at least for me `[ OK ] mme_builder_test.while_ine (0 ms)`
<eric_engestrom>
I tried leaving it running in gdb for various amounts of time, every time I break it it's in `eval_inst (sim=sim@entry=0xffffffff9848, inst=inst@entry=0xaaaaaad208f0) at ../src/nouveau/mme/mme_fermi_sim.c:283`
<eric_engestrom>
not sure how helpful that is
<gfxstrand>
Buggy on arm is possible. Other UB is also possible.
<gfxstrand>
Should have ported it to Rust. :joy:
<gfxstrand>
I do have an MR for that for the Turing MME sim.
<karolherbst>
I'll make that tool ubsan+asan clean and submit patches
frieder has quit [Remote host closed the connection]
<dcbaker>
karolherbst: sorry I didn't get back to you sooner, I had some personal stuff and was out all of last week. Did you get the bindgen + c++ stuff sorted out?
lstrano has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
<karolherbst>
dcbaker: no, as I got lost in the code :D
<karolherbst>
dcbaker: anyway, besides that I think rust.bindgen has to detect if the input is c/c++ based on how it's done with other things, maybe even add `cpp_args`, and maybe even add a toggle to force c/c++ mode
<karolherbst>
I think it's mostly the same thing, because meson shouldn't add the c++ default option if it's compiling as C
<dcbaker>
yeah, we can do that.
<dcbaker>
For sure we should handle the C/C++ detection + override
donaldrobson has quit [Ping timeout: 480 seconds]
<karolherbst>
yeah.. I kinda failed in parsing the global project options in a way it's not breaking wiht random compilers.. the biggest problem was that the compiler abstraction isn't really _that_ useful if you have tools using one of those internally
<daniels>
karolherbst, gfxstrand: not sure if you know this but you wouldn't be able to have these memory-safety errors if you rewrote it in Rust
peelz has joined #dri-devel
peelz is now known as Guest8194
karolherbst has quit [Ping timeout: 480 seconds]
illwieckz has quit [Remote host closed the connection]
illwieckz has joined #dri-devel
karolherbst has joined #dri-devel
<karolherbst>
uhh.. my system went OOM :D
<karolherbst>
why is OOM handling still so messy tho
<airlied>
so non-gsp ampere is probably going to die a lot, hell gsp ampere will also die a lot
<mupuf>
airlied: interesting. What is the gsp improving here... aside from performance?
<airlied>
not improving, just very different execution paths
<mupuf>
I assume the gsp support is not available publicly yet, right?
<mupuf>
oh, command submission goes through the GSP then?
<airlied>
nope, but all the channel allocations do
<airlied>
and the recovery
mvlad has quit [Remote host closed the connection]
<mupuf>
I see
<mupuf>
makes sense
<airlied>
and error reporting
<airlied>
the non-gsp ampere firmware is not well tested by nvidia or nouveau
<mupuf>
Sooooo, is there a tree somewhere that I could use?
<airlied>
not really yet
bmodem has quit [Ping timeout: 480 seconds]
<airlied>
imo it's a bit early to throw ci at this
<airlied>
unless you have resources to actually fix all the problems
<mupuf>
No ressources, just wanted to propose the ga106 as a manual job
fab has quit [Ping timeout: 480 seconds]
<mupuf>
and daily runs
<airlied>
if you want to hand make a gsp based ampere you could try and gather all the pieces but I think it's premature
<mupuf>
I did not buy the GPU for this, I bought it to test the nvidia driver with dxvk
<airlied>
if you can stabilise the non-gsp fw with cut down test lists or less parallelism then go for that
<mupuf>
and running nouveau was a way for me to test a lot of the parts of the infra.... before I move on to supporting OOT drivers with boot2container
<airlied>
I suspect 1 thread should be mostly stable
<mupuf>
yeah, sounds like a good plan to me
<mupuf>
4 threads seems happy right now
<mupuf>
but crashed on the first run
<mupuf>
if this is gonna be like this (will maybe crash at first), then we can just auto-retry
<airlied>
yeah there's some pretty random blow ups, we need to get to them, but CI is just going to add pressure rather than time :)
<eric_engestrom>
airlied: it wouldn't be pre-merge ci, just a manual job that's there if you want it
<mupuf>
right. So if we can identify a set of tests that reliably pass, then we can enable that
<eric_engestrom>
for regression testing in MR and such
<mupuf>
and use that to track regressions
<mupuf>
eric_engestrom: mind sending another MR with 16 threads?
* airlied
has an ampere that won't even boot with the pre-gsp fw so it's a mess to sort out
<mupuf>
I would love to see the impact :D
phryk has joined #dri-devel
<airlied>
zmike: is ../src/gallium/auxiliary/util/u_threaded_context.c:2589: tc_buffer_map: Assertion `!(tres->b.flags & PIPE_RESOURCE_FLAG_DONT_MAP_DIRECTLY)' bad?
<zmike>
yeah
Duke`` has quit [Ping timeout: 480 seconds]
<airlied>
seeing a bunch of those in nvk piglit runs
<mupuf>
eric_engestrom: actually, let's try with jobs=1. We crashed again: got an irq nouveau did not ack
<zmike>
I think that only gets set for really big buffers?
<mupuf>
nouveau 0000:2d:00.0: fifo:PBDMA0: intr0 00800000
<mupuf>
anyway, bed time!
<eric_engestrom>
yeah, bed time for me too ^^
<eric_engestrom>
mupuf: not sure what you meant by threads?
<eric_engestrom>
FDO_CI_CONCURRENT ?
<mupuf>
eric_engestrom: yes
<mupuf>
would be nice if you could set it to 1
<mupuf>
and we can run it tomorrow and see if it finishes
<mupuf>
it will take a day or so to run :D
<eric_engestrom>
sent now, we'll see how far it got when we wake up :P