mbrost_ has quit [Remote host closed the connection]
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
warpme has joined #dri-devel
kzd has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost_ has quit [Remote host closed the connection]
AndreyRibeiro_ has quit [Remote host closed the connection]
karenthedorf has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
<eric_engestrom>
zmike: jasuarez & chema would be the main contact for that farm, although they're not always on irc
<eric_engestrom>
but yeah, we're aware of this issue but haven't been able to figure it out, and we're hoping to replace this farm with a ci-tron farm soon™
<jasuarez>
Btw last week we moved some duts to another device and we commit a mistake when plugging cables. Already fixed thoug
kts has joined #dri-devel
<zmike>
jasuarez: seems like I'm getting a random piglit flake now, but last night I had some hw fails
<zmike>
don't have links unfortunately
LeviYun has joined #dri-devel
<zmike>
eric_engestrom: does ci-tron fix hardware issues?
<zmike>
cuz not booting seems like a hardware issue
<jasuarez>
I'm sorry about that. Sometimes the serial cables don't work for unknown reason. No logs in kernel about why. We are trying to figure out or minimize the problem, like retrying under this situation
<zmike>
these things happen I guess
heat has joined #dri-devel
<MrCooper>
daniels: FYI, just bisected a crash with EGL running via waypipe to 361f3622587e ("dri: Unify createImage and createImageWithModifiers")
LeviYun has quit [Ping timeout: 480 seconds]
<eric_engestrom>
zmike: ci-tron helps with configurations issues like writing down the wrong pairing of dut/serial/pdu, which there have been many of in the baremetal farm because it has to be written down by hand, while on ci-tron it's all automatically detected
<zmike>
I see
<zmike>
neat
mripard has quit [Quit: mripard]
<daniels>
MrCooper: a backtrace would be super handy
<daniels>
MrCooper: I've been told that it breaks Xwl on virtio-amdgpu but waiting to hear more
<daniels>
MrCooper: knowing the underlying driver would also be v useful
<MrCooper>
notably looks like it's picking the older GPU using the radeon kernel driver, so no modifiers
<MrCooper>
slight correction, actually it's using amdgpu, still no modifiers though
<daniels>
the contents of *surf look fine to me?
<daniels>
this is the same as what Dmitry reported on virtio-amdgpu, and it seems to be that image creation fails which leaves the swapchain without a backbuffer
nerdopolis has joined #dri-devel
coldfeet has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
Duke`` has joined #dri-devel
alih has joined #dri-devel
warpme has quit []
coldfeet has quit [Remote host closed the connection]
LeviYun has quit [Remote host closed the connection]
cyrinux has quit []
cyrinux has joined #dri-devel
coldfeet has joined #dri-devel
kts has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
kill has joined #dri-devel
rgallaispou has quit []
Company has quit [Remote host closed the connection]
<MrCooper>
daniels: create_dri_image_from_dmabuf_feedback calls create_dri_image with the linear & invalid modifiers
<MrCooper>
create_dri_image can handle that without pscreen->resource_create_with_modifiers in principle, that might go against principles of modifier-full APIs though?
Company has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
kill has quit []
<MrCooper>
daniels: FWIW, waypipe advertises the linear & invalid modifiers for all formats via zwp_linux_dmabuf_v1
Company has quit [Read error: Connection reset by peer]
<MrCooper>
so handling this in create_dri_image is fine? or should it rather be handled in create_dri_image_from_dmabuf_feedback?
<gurenta>
Hey, im trying to build mesa with meson and im failing at the clang-ccp dependency! Does anybody know the package that I need for RHEL / Oracle Linux
<soreau>
gurenta: is there a symlink libclang-cpp.so pointing to the lib? if it's in a nonstandard location, you might have to point LIBRARY_PATH to it
<soreau>
though I would like to think that wouldn't be neccessary
<daniels>
gurenta: you need clang-devel
<daniels>
(libclang-cpp.so.17 is only for runtime, you need the devel package to build things)
<gurenta>
Yep
<gurenta>
Thats it
<gurenta>
Thank you guys Thanks daniels
<gurenta>
Now it finishes
<gurenta>
tyvm
asrivats has quit [Remote host closed the connection]
Parthiban has joined #dri-devel
<daniels>
MrCooper: sorry I missed half your messages here - gonna write it up in the MR so it's more visible
gurenta has quit [Quit: Page closed]
<MrCooper>
no worries, thanks
<daniels>
np, thanks for pointing straight at the solution
<MrCooper>
o/\o
<Parthiban>
frankbinns: I have an A133 SoC which comes with GE8300 PowerVR. I tried to load the mainline driver (which is for GE8320), but unable to read the PBVNC. Existing mainline driver for GE8320 compatible with GE8300 as well? Many thanks.
asrivats has joined #dri-devel
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
leizhou has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit []
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
Mangix has quit [Remote host closed the connection]
Mangix has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
Kayden has joined #dri-devel
leizhou has joined #dri-devel
ybogdano has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
<mattst88>
I have a deref that isn't lowered in nir_lower_io because deref->modes == nir_var_mem_push_const, but state->modes == nir_var_uniform, so nir_deref_mode_is_one_of() returns false
<mattst88>
this is failing in a shader with an infinite loop, so my guess is that some information isn't getting propagated due to the wonky CFG
LeviYun has joined #dri-devel
<mattst88>
I'm not even sure if this is where such a deref should be lowered
<alyssa>
> we require that the test farm be able to handle a whole pipeline’s worth of jobs in less than 15 minutes (to compare, the build stage is about 10 minutes). Given boot times and intermittent network delays, this generally means that the test runtime as reported by deqp-runner should be kept to 10 minutes.
<jasuarez>
Right. But the overall job time including booting and so on should be around 15mim
<alyssa>
at least as of December 2023, the rest of the rpi jobs were meeting these targets with plenty of breathing room, so just the new rpi5 job that should be tweaked
<jasuarez>
It took 13 min in total
<alyssa>
yes, that's why I said "slower than the soft limit in policy though it does seem ok for the hard limit'
<alyssa>
to compare, the rpi4 jobs are e.g. 8min of deqp-runner time with a hair of 10min of total job time
LeviYun has joined #dri-devel
<jasuarez>
Ok. I'll try to adjust so test time < 10min
<alyssa>
cheers, thanks :)
AndreyRibeiro has quit []
<jimc>
howto use DRM-CI effectively ?
<jimc>
and Ive branched that to merge in my dd-fix-9 branch
<jimc>
Ive got a fork (plain old copy) of drm-next on gitlab,
<jimc>
(approx)
<jimc>
Ive set up 2 pipelines, on them respectively,
<jimc>
they are failing the same tests.
<jimc>
So I havent added any new failures,
<jimc>
but thats not exactly a ringing endorsement.
<jimc>
It would be nice to see all green both without and with my patches
<jimc>
It prompts a few questions:
<jimc>
why doesnt drm/next have a drm-ci pipeline ?
<jimc>
wouldnt that provide the current, historic status for each merge ?
<jimc>
test results on drm-next could run many times over time,
<jimc>
uncovering flakes, and providing sufficient testing to quantify "flakiness"
LeviYun has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
mvlad has quit [Remote host closed the connection]
owndgwsmehoyk^ has joined #dri-devel
owndgwsmehoyk^ has quit [Remote host closed the connection]
karenthedorf has joined #dri-devel
mbrost has joined #dri-devel
kaiwenjon has joined #dri-devel
mbrost_ has joined #dri-devel
<sghuge>
bnieuwenhuizen: pixelcluster konstantin Quick question about the ploc_internal.comp shader from BVH, is there a dependency on fixed subgroup size? or we can expect it to work with 8/16/32 etc?
<bnieuwenhuizen>
sghuge: I think we divide by an assumed subgroup size in there at least
<bnieuwenhuizen>
like all the divide by 64 for the aggregation are assumed subgroup sizes
<sghuge>
bnieuwenhuizen: ACK. Thanks for confirming that.
LeviYun has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
pinkc has joined #dri-devel
leizhou has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
jfalempe has quit [Quit: jfalempe]
LeviYun has joined #dri-devel
pinkc has quit [Ping timeout: 480 seconds]
karolherbst_ has joined #dri-devel
karolherbst has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
nerdopolis has quit [Ping timeout: 480 seconds]
leizhou has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
M3SYER[m] has joined #dri-devel
Company has quit [Read error: Connection reset by peer]