<jgmdev>
just in case opengl is broken under wayland, the commit where I first saw the issue was 723b000d279, last commit I tested without the issue is 0dfc5b51967. Tested on Weston and Wlroots and both have the same issue, GNOME fallbacks to X11
<jgmdev>
Open gl/es applications render a black window, examples chromium, glmark2, etc... meanwhile firefox doesn't renders anything (transparent).
<macc24>
huh?
<jgmdev>
ahh, this was tested on Bifrost G52
<macc24>
lemme check on my g72 box
<jgmdev>
ty
<jgmdev>
just in case latest mesa master git seems to have broken build due to gallium nine changes
<macc24>
i can say that 9b711543 works on my adreno machine
<jgmdev>
mmm
<jgmdev>
will build that with gallium nine turned off to see if the issue was fixed
<macc24>
oh yeah it brokw
<macc24>
broke*
<macc24>
but for me in a different way, for example glxinfo hung it
<macc24>
but weirdly sway didn't
<jgmdev>
sway works
<jgmdev>
I tested both wayfire and sway
<jgmdev>
but running gl apps doesn't work
<macc24>
as if sway isnt a gl app
<jgmdev>
that is the strange thing :P
<macc24>
firefox launched fine for me
<jgmdev>
glmark2, chromium?
<macc24>
i don't have glmark2
<macc24>
alyssa: something broke badly i think
<jgmdev>
any gl game would do
<jgmdev>
on X11 it still renders correctly but haven't tested with a GL compositor on X11
<macc24>
jgmdev: do you know how to bisect?
<alyssa>
uh oh
<jgmdev>
haven't got the need to do so, but could learn some new git tricks :)
<alyssa>
AFBC fail maybe
<macc24>
alyssa: i remember using afbc pan_mesa_debug option on my duet with nothing failing that badly
<macc24>
jgmdev: you just git bisect start, then tell git what commit is good with 'git bisect good <commit>' and what is bad with 'git bisect bad <commit>'
<macc24>
then just build, install and tell it if it is good or not
<jgmdev>
sounds easy... will give it a try with most minimal mesa I can for faster compiling
<alyssa>
bah
* alyssa
is knee deep into AGX compiler refactor
<macc24>
i am also busy with... ummm... stuff...
<HdkR>
Reading kernel patches myself
<HdkR>
It's a...great time
<macc24>
yeah, and i'm testing stability of mpv when watching videos through sshfs
<HdkR>
Dogfooding is important
<macc24>
tbh i don't see any other way to test if linux distro is usable
<alyssa>
=D
<macc24>
and sc7180 is fast so it's a win-win
<jgmdev>
after building latest from mesa master with gallium nine disabled it seems to work :) so I guess the issue is already solved
stikonas has quit [Remote host closed the connection]
<macc24>
seems a bit excessive to enable for example r100 or r200 in arm distro
jernej has quit [Ping timeout: 250 seconds]
jernej_ is now known as jernej
<jgmdev>
it is required for other VA stuff if I recall correctly...
<macc24>
vaapi/vdpau isn't really a mesa thing when using mali devices
<jgmdev>
mmm, will see if after disabling I still get accelerated video support on MPV
<macc24>
oh you do? cool, how?
<jgmdev>
well that is what I think, I'm not even sure :) but when playing a video I get VO: [gpu] 1920x1080 yuv420p
<macc24>
oh that tells you mpv is using gpu to display decoded video
<urjaman>
yeah that's only the output layer :P (not accelerated decoding)
<macc24>
to find if it's hardware accelerated you'd need to dig into logs when using mpv with verbose flags
<macc24>
flag* or you can just monitor cpu usage
<jgmdev>
ahh I see. on average cpu usage is on 11% up to 16%
<urjaman>
i mean you are using the GPU to scale (and likely composite...) the video (so "gpu" output certainly is better than naive framebuffer or such)
<macc24>
jgmdev: gpu doesn't decode video in most if not all arm devices
<macc24>
there are dedicated ip blocks just for video hwdec, for example hantro g1 in rk3288, or venus in sc7180
<jgmdev>
macc24: since I enabled the video decoding chipset for meson on the kernel build I thought I would at least get some video decoding
<jgmdev>
the one driver still on staging
<macc24>
you'd need to fiddle around ffmpeg/mpv/libva to get it running
<macc24>
libva driver*
<jgmdev>
I have been mistaken by not properly investigating mpv, but as urjaman says at least with gpu doing the rendering works better :)
<macc24>
afaik for now ffmpeg doesn't have it in the source tree, and libva driver isn't really suited for v4l2 request devices, that's what i got told on #kodi
<HdkR>
The real sad thing is how that build config doesn't have radeonsi or radv or iris/i965 enabled :)
<HdkR>
nor anv
<macc24>
not even hardware accelerated vulkan drivers are there, L
<HdkR>
Poor turnip
<jgmdev>
macc24: now I see what you mean: [vd] h264_v4l2m2m (h264) - V4L2 mem2mem H.264 decoder wrapper
<jgmdev>
[vd] Using software decoding.
<jgmdev>
[vd] Opening decoder h264
<jgmdev>
[vd] No hardware decoding requested.
<jgmdev>
HdkR: didn't got the joke :D (i'm too ignorant) but I do would like to test new vulkan work by brezillon
<HdkR>
jgmdev: If you're enabling some drivers that are typically PCIe add-ins then you should enable all of them, and you're also missing all the vulkan drivers, including the ones for ARM platforms
<HdkR>
v3dv and turnip are the pi and adreno vulkan drivers respectively. anv and radv are the PCIe add in ones
<macc24>
HdkR: all?
<macc24>
oh
<macc24>
wait, anv is for intel gpus and there are so far none that go onto pcie
<macc24>
pcie that is user accessible*
<HdkR>
There is one publicly launched for OEMs
<macc24>
ah
<HdkR>
And if it isn't available yet then it is on the cusp anyway. Software needs to move :)
<jgmdev>
nice to know :), since panfrost didn't supported vulkan I didn't cared much about it, I guess I could improve that config for people that may use it with other sbc's
<macc24>
jgmdev: keep that r100, maybe there is going to be someone with ati 9100 in their sbc
<jgmdev>
I tried disabling it but the build was complaining of some requirements IIRC, and I ain't got time for that :D
<macc24>
HdkR: d-did you just admit that you have x86 computer?
<HdkR>
Until there is an ARM Threadripper competitor, yes.
<macc24>
a stack of 8cx laptops would be as powerful as threadripper
kaspter has joined #panfrost
kaspter has quit [Excess Flood]
<HdkR>
distcc bottlenecks aren't though
kaspter has joined #panfrost
<HdkR>
That's the exact command I use for building mesa for FEX's RootFS though
Depau_ has quit [Remote host closed the connection]
Depau has joined #panfrost
<jgmdev>
nice ty, I would like to try fex but guess my sbc isn't up to the job
<macc24>
jgmdev: what do you have?
<jgmdev>
N2+, C4 and HC4, but I rarely use the latters
<macc24>
oh, a55, C4 would work, HC4 would work too
<HdkR>
Just won't be a great experience with the slowness :P
<macc24>
HdkR: i couldn't even get fex to run on my sc7180 laptop so xD
<macc24>
and tbh if mono sgen thing doesnt work then :(
<HdkR>
It's coming. Mono SGen and bdwgc should both be hooked up before the end of may
<macc24>
oh that reminds me of minecraft on my lazor hmmmmmmmm
<macc24>
damn, end of may is a long time
<jgmdev>
all I would like is to run some apps not available for ARM (which is rare, mostly drm stuff and one can get that on armv7 bins), running steam would crawl so I don't get excited about that :)
<macc24>
uh oh, my xeon desktop made a weird noise i think it hung again
<macc24>
coil whine is useful xD
<HdkR>
jgmdev: One of the sad bits about Steam is that CEF has a 10 second timeout window which makes emulation have performance minimum requirements
<HdkR>
Also steam needs kernel patches. Which is exactly what I'm working on right this minute
<macc24>
oh i think i can get a screenshot of steam running on my arm64 laptop totally not streamed from x86 computer
<jgmdev>
HdkR: nice, you are preparing the path for the future more powerful ARM I wish will be developed soon!
<jgmdev>
I mean, one can already get phones with powerful cpu's but not friendly sbc's
<HdkR>
macc24: That reminds me, I need to test Steam Link again since we fixed some threading bugs. Probably works fine
<HdkR>
jgmdev: That's what I'm here for. Windows and MacOS already has a working solution, Linux needs a real one
<HdkR>
(qemu isn't a working solution)
<macc24>
HdkR: muh full system emultaion
<HdkR>
qemu still has its uses outside of FEX :)
<macc24>
yeah but.... fast full system emulation
<HdkR>
Impossible
<macc24>
why
<HdkR>
and unwanted really. Qemu is meant to be easy to hammer on
<HdkR>
fast and full system emulation will always have trade offs that are undesired :)
<macc24>
but why
<HdkR>
Because full system emulation implies that there aren't going to be any hacks or cheats to get something fast
<HdkR>
If you're emulating an MMU then it isn't going to be fast
<macc24>
oh ok
<HdkR>
This is one of the major wins for qemu-user as an example
<jgmdev>
HdkR: you are a hero :D
<HdkR>
I'm a human that got lucky :)
davidlt has joined #panfrost
<icecream95>
dhewm3 is now giving me DATA_INVALID_FAULTs, time to get bisecting...
<alyssa>
preemptive sorry.
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #panfrost
<icecream95>
ff3eada7eb4 ("panfrost: Use the generic preload and FB helpers in the gallium driver") is the first bad commit
<alyssa>
it passed CI therefore it must be bug free /s
vstehle has joined #panfrost
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #panfrost
<bbrezillon>
daniels: with AFBC_SPLIT support, weston now uses an AFBC mod for its background. I changed the background color to 0xff0000ff (blue) and checked the result with and without the change I pointed to, and it only works when I pass the format swizzle to the render target, otherwise R and B components are swapped
<bbrezillon>
icecream95: /o\
<bbrezillon>
alyssa: ah, border colors, right, I forgot this was the problem
davidlt has quit [Ping timeout: 246 seconds]
wwilly has joined #panfrost
<macc24>
damn i read it as "<jgmdev> HdkR: you are a herd :D" and was thinking what it could mean xD
<HdkR>
oops
nlhowell has joined #panfrost
<jgmdev>
macc24: that would have been an insult... anyways I changed the mesa configure flags to enable the extra drivers and with noveau was enough to provide the requirement for other flags so dropped the r100, r200 stuff
guillaume_g has joined #panfrost
guillaume_g has quit [Remote host closed the connection]
<bbrezillon>
icecream95: is it on Bifrost or Midgard?
<macc24>
bbrezillon: i've seen similar faults on g72 yesterday, thought it was my setup
<icecream95>
bbrezillon: G72
guillaume_g has joined #panfrost
<bbrezillon>
macc24, icecream95: any chance you could provide an apitrace?
<raster>
any issues with making panfrost less optimisitc about everything going right and well and making it handle errors like mmap/lseek fails gracefully (removd some asserts in the process and have it handle this without taking an entire process down)
<alyssa>
tomeu: ^
<raster>
this is interesting... there is no way to know this is invalid ... not from eglcreatimage ... :)
<raster>
even if dri2_create_image_from_winsys() fails and returns null..
<raster>
oh what? it doesnt reutrn NULL? hmm where does this break down
<robher>
HdkR: Will or Catalin on #armlinux will happily shoot it down for you I'd guess.
<HdkR>
Well, I'd /prefer/ it not shut down. Trying to do everything in my power before annoying the ML :)
<HdkR>
Last time I asked there the only response was crickets
<raster>
oh my patch was silly.. <= 0 wont return null ... never mind but the principle is the same - or question - more robust is better right? disabling some asserts and punting the error back out fo egl as a null eglimage...
<HdkR>
Being robust is good :)
<HdkR>
If it is within EGL spec of course
<raster>
well deep in panfrost mmap is failing because lseek returns -1 ...
<raster>
inside the eglcreateimage. right now mesa will soon enough abort as it tries to munmap a 0xfffffffffff address which was the reutrn of mmap failing...
<raster>
imho its better to not abort/assert and instead fail gracefully back out to the app with a null eglimage
<HdkR>
Very cute
<raster>
but right now panfrost decides an abort is a much better idea :)
<raster>
the buffer fd is invalid it seems
<HdkR>
I assume this is eglCreateImage or something?
<raster>
(dmabuf import)
<raster>
yes
<HdkR>
Then yea, that can return EGL_NO_IMAGE on failure. So more robustness is more better
<raster>
have to eglcreateimage every time we render
<raster>
so its kind of common...
<raster>
there. now it punts out a null (no image)
<alyssa>
INTERSECT on a colour / ZS resp preload shader is safe <==> clean tile writes are disabled for colour / ZS resp <===> there is no clear for colour / ZS resp <===> there is a preload for colour / ZS resp
<alyssa>
where is my chain of reasoning wrong
<alyssa>
icecream95: alyssa/blit-fixes, might be worth taking for a spin
<alyssa>
(needs the EARLY_ZS thing fixed I guess, my board is v7)
<alyssa>
running it through CI now
<alyssa>
and by "CI" i mean that SBC in the laundry room
<HdkR>
CI running or laundry, who knows?
<alyssa>
xq no los 2
jgmdev has quit [Quit: No Ping reply in 180 seconds.]