<karolherbst>
itoral: I'm trying to debug vulkan on my pi4, but the display side doesn't get properly initialized with an upstream kernel, anything I need to consider there?
<itoral>
@karolherbst: sorry but I only work with the downstream kernel from Raspberry Pi OS... @mairacanal do you know if there is something specific that needs to be done to use the upstream kernel successfully?
<karolherbst>
one error I'm seeing is "vc4_hdmi fef00700.hdmi: Could not register PCM component: -517"
<karolherbst>
and "platform gpu: deferred probe pending"
krushia_ has quit [Read error: No route to host]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
warpme has quit []
warpme 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
<Company>
karolherbst, itoral: Last I tried on my rpi4 a few weeks ago, Vulkan on Fedora was a no-go, too
<karolherbst>
it looks like something is missing on the audio side of things
<karolherbst>
I myself simply run into "deqp-vk: ../src/broadcom/vulkan/v3dv_device.c:857: create_physical_device: Assertion `display_device' failed."
<karolherbst>
and I concluded that was due to vc4 not loading correctly
<karolherbst>
which is the default behavior on fedora afaik
jsa has quit [Ping timeout: 480 seconds]
<itoral>
but if the display driver is not loading at all then GL should be broken too, but Company was talking specifically about Vulkan, so I think these are two different issues
u-amarsh04 has quit [Remote host closed the connection]
<Company>
yeah, that's why I asked
vliaskov has quit [Read error: No route to host]
<Company>
GL worked
<Company>
itoral: last time I tried was around the time of the Fedora GTK bug a few weeks ago I think
<karolherbst>
huh.. I wonder why I run into issues then
<karolherbst>
unless it's something dev board specific
<karolherbst>
or compute module
<Company>
the Fedora kernel also spams my syslog every time I use GL
zxrom has joined #dri-devel
<itoral>
MMU errors? yeah, that is a known issue, we are looking into it
<Company>
it was a bit distracting when benchmarking - the journal taking 30% of the recorded CPU time was a bit much
<Company>
I didn't really dive into the rpi too much though, basically just boot it every few weeks/months to see how well GTK works
<Company>
because I decided to use it as the example of low end hardware to target for GTK
<karolherbst>
all I can say is that the vc4 driver doesn't load on my CM4 here
<itoral>
ouch, yeah
<itoral>
@karolherbst: ok, maybe @mairacanal can help with that when she is online, not sure if she knows anything about that
<javierm>
karolherbst: what does cat /sys/kernel/debug/devices_deferred say ?
jsa has joined #dri-devel
<karolherbst>
gpu
<karolherbst>
but anyway.. I already mentioned above that it's most likely due to "of_dma_find_controller: can't find DMA controller /scb/dma@7e007b00"
<karolherbst>
and that requires a driver handling "bcm2711-dma"
<karolherbst>
which doesn't exist upstream
vliaskov has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
<javierm>
karolherbst: and are you using the upstream device tree for the CM4 ?
<karolherbst>
I don't know
<javierm>
because grep doesn't find that node in arch/arm/boot/dts/broadcom/bcm2711*
<karolherbst>
how can I check what device tree is used and how can I make it use another one?
<javierm>
karolherbst: it depends on what firmware you are using to boot (edk2 or u-boot) but if you are using Fedora, you can force the device tree to use by adding a "devicetree" entry to the BLS configs in /boot/loader/entries/
<karolherbst>
though I guess I'd need to use the "bcm2711-rpi-cm4-io.dtb" one
<javierm>
karolherbst: it seems so, yeah
<karolherbst>
there is also this /boot/efi/config.txt file doing some dt stuff
<javierm>
karolherbst: one sec, I've a rpi4 (not CM4 but the normal board) in a drawer. Let me boot it so we can compare configs
<karolherbst>
I love how nothing tells me how to use the device_tree property :)
<tzimmermann>
jani, i've been working on udl and came up with something. i'll put you in cc
<tzimmermann>
the one thig that still puzzles me is why drm_edid_read_ddc() even bothers to test connector->force. it could read the edid unconditionally and let other layers deal with connector status
jsa has quit [Ping timeout: 480 seconds]
<jani>
tzimmermann: I think a lot of places use EDID read as a way check if the display is connected. lots of places other than .detect() also have EDID reads. override/firmware EDID read always succeeds.
<jani>
ddc probe and override/firmware EDID should be orthogonal things
<jani>
but if you have the connector forced on, for example because the ddc is bust, why would you do ddc probe, possibly leading to errors and timeouts
<jani>
and finally, why are override/firmware EDIDs handled at the lowest level? this didn't use to be the case. but then we didn't actually use the override/firmware EDID for all information, it was haphazard at best. now they are handled almost exactly the same as regular EDIDs
<jani>
perhaps you could make the case that we should pass connector to drm_probe_ddc(), and have that check connector forcing
<tzimmermann>
i'm not saying that there aren't reasons. it's just pretty. it's not obvious or discoverable what's going one
<jani>
I don't disagree
<jani>
this is something I could write a bit more documentation on
<jani>
(I presume you mean "not pretty")
janneg has joined #dri-devel
surajkandpal has quit [Ping timeout: 480 seconds]
<tzimmermann>
yeah, "not pretty"
<tzimmermann>
and "on" instead of "one"
<jani>
tzimmermann: I also think the bridge funcs .edid_read() hook has lead to some bad habits, some drivers just directly using whatever mechanisms for EDID reads, instead of a) implementing the i2c ddc interface, or b) even using drm_edid_read_custom() or the older version of it
<jani>
very tedious to fix or get aligned with the rest afterwards
<jannau>
karolherbst, javierm: https://bugzilla.redhat.com/show_bug.cgi?id=2246428 upstream changed the HDMI audio dma engine. I should have send the patch which just breaks HDMI audio. patch is hacky though
pcercuei has joined #dri-devel
<karolherbst>
ohh.. so it looks like fedora 39 fixes this?
<karolherbst>
or did it break recently due to fixing this?
<karolherbst>
oh wait
klemm has joined #dri-devel
<jannau>
karolherbst: I think it was "fixed" in fedora by always using ext4 as /boot partition
<karolherbst>
huh? How is that even related?
<jannau>
the issue was server image specific and caused by fedora's u-boot not being able to load the dtb from disk
<karolherbst>
ohh....
jsa has quit [Ping timeout: 480 seconds]
<mairacanal>
karolherbst, I tested drm-misc-next on RPi 4 yesterday using Raspberry Pi OS and Vulkan was running just fine
<mairacanal>
let me know if this fedora workaround worked for you, otherwise I can grab an sd card and flash F39
chloekek has joined #dri-devel
jsa has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
simon-perretta-img has joined #dri-devel
mripard has quit [Remote host closed the connection]
mripard has joined #dri-devel
<tomasuto>
liblzma hahaa cool. I said you lose on the path of conspiring against me. I am extremely loved person in life. You get destroyed entirely.
Daanct12 has quit [Quit: WeeChat 4.2.1]
Daanct12 has joined #dri-devel
<cwabbott>
robclark: who's the point of contact for the collabora a618 test farm?
<cwabbott>
it might need to be disabled because it's causing huge (10 hr+) marge queues
<cwabbott>
it's not completely broken, but there's some kind of underprovision resulting in 45 min+ job runtimes that's slowing down marge enough to be backed up
<robclark>
cwabbott: daniels or DavidHeidelberg can check on the status.. I'd been using ci_run_n_monitor.sh yesterday to work on cleaning up a618 expectations yesterday but it should have just been running two jobs
<zmike>
nah it's been broken overnight too
<zmike>
so unless you were pulling some extremely long hours...
<robclark>
collabora does have some usage monitoring, so I guess they can check
mripard has quit [Remote host closed the connection]
mripard has joined #dri-devel
kts has joined #dri-devel
sgruszka has quit [Quit: Leaving]
simon-perretta-img has quit [Read error: Connection reset by peer]
mripard has quit [Remote host closed the connection]
simon-perretta-img has joined #dri-devel
itoral has quit [Remote host closed the connection]
<robclark>
cwabbott, zmike: looks like right now karolherbst, marge, and gfx-ci-bot (nightly runs) are currently running things on them.. but there are a lot of them and they all appear to be running fine.. I think it's just that folks are running lot of jobs. AFAIU, LAVA should attempt to prioritize marge.. but I think it just comes down to busy-ci-day
<zmike>
gdit karol
<zmike>
I knew this was all your fault
<robclark>
maybe they were also getting some drm/ci use, but that isn't massively parallel, I think just uses a couple runners
<karolherbst>
the perks of touching core stuff
simon-perretta-img has quit [Ping timeout: 480 seconds]
<cwabbott>
there were only 2 a618 jobs for that, because it only touched zink code, but it still took 10 mins
<cwabbott>
it does seem like something else is "fighting" for runner bandwidth and marge is losing
<karolherbst>
that's the a618 one, right?
<karolherbst>
mhh
<karolherbst>
a618_vk being split across 12 jobs might be a problem here
kts has quit [Quit: Leaving]
<robclark>
there are a lot of vk tests.. blame khronos, I guess?
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
warpme has quit []
apinheiro has quit [Quit: Leaving]
warpme has joined #dri-devel
<prime>
autojoin add
Daanct12 has quit [Quit: WeeChat 4.2.1]
Leopold_ has joined #dri-devel
max has joined #dri-devel
max has quit []
max has joined #dri-devel
max is now known as mripard
fab has quit [Quit: fab]
Leopold_ has quit []
kts has joined #dri-devel
<tomasuto>
My presentation for XDC is very simple, it comes out of my private one man lab testings, and everything is logged from irc on my disk, it's calculations I made in very clever fashion, so I have not kept any secrets. I spent a lot of time to simulate hardware, so if you turn me down, I accept it and promise not to sanction for this decision, I then continue with my own company and with my best friends, but I urge you not to send any
<tomasuto>
of your braindead terrorists on to my physical territory, to some degree I still respect David airlie and open source programmers, all has worked out great to me imo and you have done good work time to time, I think David is smarter than brainless criminals.
rgallaispou has joined #dri-devel
fab has joined #dri-devel
macromorgan_ has quit []
macromorgan has joined #dri-devel
<tomasuto>
I already gave most the submission data to Karol too, it's all based of that, it has been somewhat clear for me for a little while, so testing was successful, I tested the proof in very clever way, so if you want to see me presenting myself instead of Karol or Dave , then give me some appointment and submission process info to get accepted to XDC or linuxconf or fosdem.
kts has quit [Ping timeout: 480 seconds]
Ryback_ has joined #dri-devel
tomasuto has quit [Remote host closed the connection]
jfalempe has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
warpme has quit []
jsa has quit [Ping timeout: 480 seconds]
<Company>
what's the status of Vulkan on Mali?
<Company>
I guess I'm mostly wondering what's gonna happen to robertmader[m]'s dmabuf stuff once GTK goes Vulkan - that's gonna stay with GL I guess?
<DemiMarie>
Company: there is a lot of hardware that will never support Vulkan.
<DemiMarie>
So if GTK requires Vulkan, this hardware will be stuck with lavapipe.
<DemiMarie>
And it likely has far less CPU resources than Qubes OS VMs do.
<Company>
nah, we're not gonna require Vulkan - but we might have features that are Vulkan-only
jsa has joined #dri-devel
simon-perretta-img has quit [Read error: No route to host]
krushia has joined #dri-devel
simon-perretta-img has joined #dri-devel
<DemiMarie>
Company: Such as?
robert_mader has joined #dri-devel
<Company>
memory management is easier with Vulkan
<Company>
we can allocate dmabufs with it
<robert_mader>
Company: why would going Vulkan be any problem? GL and Vulkan are both implemented on top of dmabuf - and Wayland only uses dmabuf as well.
<Company>
robert_mader: because your rockchip doesn't do Vulkan
sudeepd has joined #dri-devel
<robert_mader>
Err, do you plan to drop GL from GTK? Then I'd worry about other things :P
<Company>
no
<Company>
but there's features that are easy with Vulkan
<Company>
like creating dmabufs
<robert_mader>
Sorry, I'm not following you. What does that have to do with "my dmabuf stuff"?
<robert_mader>
You are referring to wayland offloading, no? In that case we're using dmabufs from other producers anyway.
<Company>
for now, yes
simon-perretta-img has quit [Ping timeout: 480 seconds]
<Company>
there's been talk about offloading GtkGLArea for example
<zamundaaa[m]>
Company: you ideally shouldn't use either Vulkan or OpenGL if you want to create dmabufs. If you want direct scanout to work, you have to use GBM
warpme has joined #dri-devel
<Company>
zamundaaa[m]: if you want the 100% guaranteed thing, maybe
<zamundaaa[m]>
No, if you want it to work on most hardware
<robert_mader>
Company: I don't see why you'd ever want to create dmabufs for hardware video decoding :P
rasterman has quit [Quit: Gettin' stinky!]
simon-perretta-img has joined #dri-devel
<Company>
robert_mader: I wouldn't - but that's not the only usecase
<zamundaaa[m]>
EGL's default format modifier selection on modern AMD GPUs at least does not work for direct scanout
<Company>
robert_mader: actually, we talked about doing it anyway
<zamundaaa[m]>
And really shouldn't, as scanout formats are usually less efficient for rendering
<zamundaaa[m]>
Especially on tiler GPUs
simon-perretta-img has quit [Read error: Connection reset by peer]
<Company>
zamundaaa[m]: I'll wait for v4l and pipewire to figure things out then
<robert_mader>
Company: is there any reason why you'd *not* want to support importing dmabufs?
simon-perretta-img has joined #dri-devel
<DemiMarie>
Company: does GTK work with applications that use Vulkan internally?
<Company>
robert_mader: importing dmabufs works fine - the fun stuff is offloading CPU memory (we talked about that before) and offloading GtkGLArea
<Company>
DemiMarie: I have no idea - but I don't see why not, as long as they exchange dmabufs with GTK
<DemiMarie>
Company: in a portable way, as opposed to Linux-specifc
<Company>
I have no idea how that would even look
<DemiMarie>
GTK already has OpenGL support I believe
<Company>
yes, and that's already bad enough
<DemiMarie>
In what ways?
<Company>
it's basically underdefined how sharing works because there's always yet another GL thing that somebody could do
<Company>
set some TexParameter that GTK doesn't even know about etc
<DemiMarie>
On Linux: Wayland subsurface
<DemiMarie>
Also, is there anything that can be done to speed up shader compilation?
<DemiMarie>
Context: Qubes OS users often use disposable VMs, in which the shader cache will always miss.
<Company>
you don't want to share subsurfaces
<Company>
that's as bad as sharing GL textures because of all the extensions
<DemiMarie>
I meant provide a subsurface for the app to use
<Company>
same problem
<DemiMarie>
So GTK is not suitable for games, got it.
<Company>
you want to share dmabufs or another memory abstraction
<Company>
I don't think GTK is suitable for games until people start adding support for it - but that has nothing to do with buffer sharing
<Company>
and more to do with how the frame clock works
jmondi has quit [Quit: WeeChat 3.8]
Duke`` has joined #dri-devel
Calandracas_ has quit [Remote host closed the connection]
kts has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
Calandracas has joined #dri-devel
sarnex_ has quit []
sarnex has joined #dri-devel
klemm has quit [Ping timeout: 480 seconds]
mripard is now known as Guest77
mripard has joined #dri-devel
davispuh has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
klemm has joined #dri-devel
Guest77 has quit [Ping timeout: 480 seconds]
mripard has quit [Ping timeout: 480 seconds]
kts has quit [Remote host closed the connection]
klemm has quit [Ping timeout: 480 seconds]
imre is now known as Guest80
imre has joined #dri-devel
Guest80 has quit [Ping timeout: 480 seconds]
mahkoh has joined #dri-devel
<mahkoh>
Would it be possible to add a syscall to create syncobj fds independently of any DRM fd? I'm running integration tests of my compositor on a headless system with only vkms (IIRC) and I cannot test the explicit sync paths because I cannot create syncobjs.
kj2 has quit []
klemm has joined #dri-devel
sudeepd has quit [Ping timeout: 480 seconds]
<mairacanal>
have you tried vgem?
<mahkoh>
I have not. All I'm doing right now is `modprobe vkms` before running my tests and then my test backend picks up the first entry in /dev/dri and uses that for rendering + creating syncobjs. I'll look into vgem.
tobiasjakobi has joined #dri-devel
imre has quit [Ping timeout: 480 seconds]
tobiasjakobi has quit []
tomasuto has joined #dri-devel
klemm has quit [Ping timeout: 480 seconds]
warpme has quit []
klemm has joined #dri-devel
sudeepd has joined #dri-devel
Haaninjo has joined #dri-devel
<tomasuto>
DemiMarie, there is actually no gpu in the world that could not support vulkan, after my presentation i mean you would understand that, i could add those entries, and it is actually possible also to convert opengl to opengl es, as is possible to convert between any rendering api. You would end up doing things in sw land. Today we have everything, i much liked the commit and idea of GUD, it was the last thing i missed.
klemm has quit [Ping timeout: 480 seconds]
<tomasuto>
but finding a way to communicate this process to intel and amd employers , they are not probably fine to employ you to do that, i suppose red hat and such is cool.
<mahkoh>
I tried using vgem but this causes the following errors: `DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied`. The same does work with vkms. Also as far as I can tell that driver does not support syncobjs either: `.driver_features= DRIVER_GEM | DRIVER_RENDER,`
klemm has joined #dri-devel
tomasuto was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
<mahkoh>
The reason for the permission denied seems to be that vgem creates a render node and render nodes don't allow creating dumb buffers. vkms does not create a render node so everything works. I'll try deleting the render node before running the tests.
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<robert_mader>
DemiMarie: for the record - GTK *does* unofficially support app-controlled subsurfaces - that's how Firefox works. While that's with GTK3, which won't change much any more, AFAICS it should mostly work with GTK4. But given that it's not officially supported you probably shouldn't build a game with it :)
klemm has quit [Ping timeout: 480 seconds]
<mahkoh>
After deleting the render nodes I'm running into a different problem where it looks like I can no longer create an opengl context. Guess I'll just not be able to run syncobj tests automatically.
robert_mader has left #dri-devel [#dri-devel]
mahkoh has quit [Quit: Page closed]
simon-perretta-img has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
kts has quit []
imre has joined #dri-devel
rgallaispou1 has joined #dri-devel
simon-perretta-img has joined #dri-devel
rgallaispou has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
mbrost has joined #dri-devel
rgallaispou1 has quit [Read error: Connection reset by peer]
rasterman has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
chloekek has quit [Remote host closed the connection]
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
anholt has quit [Quit: Leaving]
mbrost has quit [Ping timeout: 480 seconds]
krushia has quit [Ping timeout: 480 seconds]
aswar002_ has quit []
aswar002 has joined #dri-devel
Company has quit [Quit: Leaving]
jkrzyszt has quit [Quit: Konversation terminated!]
Kayden has quit [Quit: -> JF?]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<DemiMarie>
@_oftc_robert_mader:matrix.org: is there a reason it cannot be official? I thought that having different libraries use different subsurfaces was intended behavior.
Calandracas has quit [Remote host closed the connection]
Calandracas has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
rasterman has joined #dri-devel
<airlied>
dwfreed: ^ just in case you missed it :-)
mvlad has quit [Remote host closed the connection]
fab has quit [Quit: fab]
Kayden has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Ojus1_ has joined #dri-devel
mbrost has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
jsa has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
asrivats_ has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
<dwfreed>
airlied: yeah, got a PM from another
balrog has quit [Remote host closed the connection]
balrog has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
Guest99 has joined #dri-devel
Guest99 has quit []
Marcand has joined #dri-devel
Ojus1_ has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
simon-perretta-img has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: -> home]
zxrom has quit []
paulk has quit [Ping timeout: 480 seconds]
paulk has joined #dri-devel
paulk has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
glennk has quit [Ping timeout: 480 seconds]
paulk-bis has joined #dri-devel
simon-perretta-img has joined #dri-devel
bgs has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
bgs has quit [Remote host closed the connection]
psykose has quit [Remote host closed the connection]
bgs has joined #dri-devel
psykose has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
psykose has quit [Remote host closed the connection]