ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
camus has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
iive has quit []
toolchains has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
toolchains has joined #dri-devel
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
columbarius has joined #dri-devel
toolchains has quit [Read error: Connection timed out]
co1umbarius has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
toolchains has joined #dri-devel
camus has quit [Remote host closed the connection]
toolchains has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Remote host closed the connection]
camus has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
toolchains has joined #dri-devel
camus has quit [Remote host closed the connection]
off^ has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts_ has joined #dri-devel
toolchains has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
pixelcluster has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
pixelclu- has quit [Ping timeout: 480 seconds]
kts_ has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
off^ has joined #dri-devel
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
off^ has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
srslypascal has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
Terman has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
off^ has joined #dri-devel
g0b has quit [Remote host closed the connection]
g0b has joined #dri-devel
camus has joined #dri-devel
off^ has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
Duke`` has joined #dri-devel
off^ has joined #dri-devel
toolchains has joined #dri-devel
Company has quit [Quit: Leaving]
off^ has quit [Ping timeout: 480 seconds]
off^ has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
off^ has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
off^ has joined #dri-devel
toolchains has joined #dri-devel
off^ has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
toolchains has joined #dri-devel
bmodem has joined #dri-devel
bmodem has quit []
toolchains has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
dv_ has joined #dri-devel
toolchains has joined #dri-devel
LexSfX has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
abws has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
ced117 has joined #dri-devel
gouchi has joined #dri-devel
ced117 has quit [Quit: leaving]
ced117 has joined #dri-devel
toolchains has joined #dri-devel
gouchi has quit [Quit: Quitte]
ced117 has quit [Quit: leaving]
ced117 has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
sarnex has quit [Read error: Connection reset by peer]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
phaddad has joined #dri-devel
lemonzest has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
Danct12 has quit [Quit: Leaving]
<phaddad> Hello. I have a really simple (probably stupid) question. I am currently building LFS/BLFS targeted for specific embedded hardware and in regards to a southern islands AMD/ATI GPU with Mesa, I know LLVM is required for GalliumSI and radeonSI but once I have built it all do I still need the LLVM compiler/libraries on my target system?
<ishitatsuyuki> phaddad: LLVM is linked dynamically by default, set shared-llvm (meson option) to false to static link
<phaddad> ishitatsuyuki: so you are saying at the end of the day LLVM libraries will be required on the target if built dynamic
<ishitatsuyuki> do you know what dynamic linking is?
<phaddad> Yes
<ishitatsuyuki> I think dynamic linking obviously implies there's a runtime dependency
<phaddad> OK, its just I didn't see the any of the mesa libraries dependent on LLVM libraries through ldd
<ishitatsuyuki> the libgl.so etc is just a loader
<ishitatsuyuki> /usr/lib/dri/radeonsi_dri.so is the actual driver
<phaddad> I see
<phaddad> So try and configure Mesa to link statically to LLVM?
<phaddad> thanks ishitatsuyuki I appreciate the info
<ishitatsuyuki> yes if you want to avoid a runtime dependency on that link statically
<phaddad> I was hoping it wasn't needed because I'm trying to make everything byte for byte reproducible, but I suppose if LLVM libraries aren't by default reproducible it wouldn't matter whether it was static or dynamic
<ishitatsuyuki> no idea for reproducibility but for radeonsi LLVM is an non-optional dependency right now
<phaddad> OK, does radeonsi provide a huge performance benefit over normal radeon?
karolherbst_ has joined #dri-devel
<ishitatsuyuki> I don't know what normal radeon you are talking about
<ishitatsuyuki> there are only 2 mesa drivers for amd, radeonsi and r600 and I think r600 also uses LLVM
karolherbst has quit [Remote host closed the connection]
<phaddad> ahhh thats right r600
<phaddad> ok thanks again
<ishitatsuyuki> performance wise you need to do your own benchmark, generally r600 is preferred for old hardware for stability since radeonsi development activity happens around latest gen hw
<phaddad> thats good to know, I think you can currently disable llvm for r600
<phaddad> so long as the configure options work
<ishitatsuyuki> ... I don't think it will work
<ishitatsuyuki> there's no alternative backend that can generate AMD assembly
<ishitatsuyuki> basically the only other option is ACO, but that was made for RADV and not ported to radeonsi yet
<phaddad> radv is for vulkan right?
<ishitatsuyuki> yes
<phaddad> Right, well here's hoping I can make it all reproducible :)
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
<javierm> robclark: I have another data point on the issue I was investigating yesterday. It's related to some clock being gated (and that's what leads to those -EBUSY) that cause the probe failure
<javierm> robclark: with clk_ignore_unused it does work correctly. So I guess it's either a clock driver I'm enabling that you aren't or I'm missing some driver that also grabs that clock and it remains ungated
<javierm> but couldn't figure out what those should be. I wonder if the mdss_dp DTB node in sc7180.dtsi is missing some required clocks
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
sarnex has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
alarumbe has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
toolchains has quit [Ping timeout: 480 seconds]
gouchi has quit [Quit: Quitte]
heat has joined #dri-devel
KaitoDaumoto has joined #dri-devel
<robclark> javierm: hmm, clk_ignore_unused fixing display on chromebooks is a bit odd because the depthcharge disables the display before jumping to kernel.. so we don't have the headaches caused by display already being enabled
<robclark> javierm: https://paste.centos.org/view/25fb5fae <-- my clk_summary.. compare that to yours and see what clks are missing?
<javierm> robclark: I think the culprit is gcc_mss_cfg_ahb_clk that's gated when fails
<javierm> robclark: and yeah, noticed that depthcharge disables the display (since simpledrm doesn't work) but didn't know if gated all the clocks used by the display controller
<robclark> it is supposed to disable the clks
<javierm> robclark: I see
<javierm> interesting
<robclark> hmm, gcc_mss_cfg_ahb_clk doesn't seem to be in the hierarchy for anything display related
<robclark> and it's not enabled for me but display is on
<robclark> I suspect it is unrelated
<javierm> robclark: I'm not familiar with qcom SoCs but was just a guess by looking at the .dtsi
<javierm> let me compare with your clk hierarchy
<javierm> robclark: what about gcc_disp_hf_axi_clk ?
<javierm> that's indeed display related and is gated in my hierarchy while ungated in yours
<robclark> ahb.. I think that would be a clock needed to access registers on some bus.. ie. it would SError and reboot if you accessed some hw block without it enabled.. axi otoh is the memory interface for the block
<robclark> that would need to be on for display to scanout
<javierm> robclark: yeah, and since as you mentioned is a clk to access the bus, then would explain the -EBUSY errors
Company has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<javierm> hmm, but we both have CONFIG_SC_GCC_7180=y so I don't really understand if that was the problem
<robclark> so GCC will provide some parent clk(s) for DISPCC
<robclark> but it looked like you had all that
<robclark> if diffing your clk_summary with mine shows some clks missing in yours that are in mine that would be a hint
<javierm> robclark: yup, and also enabled the drivers for "qcom,mdss-dsi-ctrl" and "qcom,sc7180-dpu" that should enable that clock
<javierm> anyways, I think that will just forget about this issue and just boot with "clk_ignore_unused" in the meantime until someone fixes it :)
<robclark> paste again the link for your .config and dmesg and maybe abhinav__ can take a look when he is around?
<robclark> everything I check in your .config vs mine.. yours looks more or less like a superset ;-)
<javierm> robclark: yeah, I took the .config from a repo that was meant to build a FIT image for different chromebooks and trimmed it down a little bit
<robclark> fwiw, I started w/ the qc chromebook config, added a few things fedora wants (btrfs, etc).. then olddefconfig + add PANEL_EDP
<robclark> that should be a pretty reliable way of getting a working config
<javierm> robclark, abhinav__: https://paste.centos.org/view/raw/b00c2eac for .config and https://paste.centos.org/view/raw/4c6e6589 for dmesg -k
<javierm> robclark: thanks for the info. I may go that route or just replace mine with yours. I got curious about what was going on but hard to figure out without the SoC documentation
kts has joined #dri-devel
<robclark> it's hard to figure out *with* that documentation.. ;-)
<javierm> :)
<javierm> robclark: btw, about the mutexes I think that figured out what was happening. Posted https://lists.freedesktop.org/archives/dri-devel/2022-July/365625.html
<robclark> there are at least three clk drivers plus interconnect and genpd needed to make display work ;-)
* robclark looks
alarumbe has joined #dri-devel
<robclark> lgtm
<javierm> robclark: I should learn to try adding "clk_ignore_unused pd_ignore_unused" as the first try each time that I get these errors
<javierm> it "fixes" in the vast majority of the cases :)
<javierm> robclark: thanks for looking at it. Let see what others think about that. I also wondered if we should WARN_ON on NULL drm_device in drm_atomic_helper_shutdown()
<robclark> the _ignore_unused flags can cause problems later, like dpms.. if you are missing the driver to control some clk, some other clk could get stuck on when trying to disable.. but it is a useful hint to figure out which of clk_ignore_unused and pd_ignore_unused "fixes" things or whether you need both
<robclark> hmm, don't have a strong opinion about WARN_ON() for null vs just returning like kfree type APIs do
<javierm> robclark: yeah. Hence the quotes on fixes since things are going to break anyways for example if I do a suspend-to-ram
<javierm> btw, this HP X2 is a great device. I really like the form factor of a tablet with a detachable keyboard
toolchains has joined #dri-devel
<robclark> yeah, I got my mom one.. she likes it.. but running CrOS
<robclark> does the stylus work w/ anything on linux?
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<javierm> robclark: haven't tried it yet. I use CrOS as a daily driver but have Fedora installed on a USB pendrive
<robclark> I guess I could try a coachz stylus on my lazor and see.. the styluses (styli?) should be interchangeable
<robclark> we do have some fun tricks in CrOS for reducing the latency (basically front-buffer rendering to an overlay).. would be neat if wayland could learn to do similar tricks
<javierm> cool
toolchains has quit [Read error: Connection timed out]
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
<graphitemaster> So driver devs, how much do you like transform feedback involving a geometry shader on instanced objects
<graphitemaster> Or did I just give you a heart attack
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
moa has joined #dri-devel
toolchains has joined #dri-devel
bluebugs has quit [Ping timeout: 480 seconds]
off^ has joined #dri-devel
bluebugs has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
moa has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
moa has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
bluebugs has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
toolchains has joined #dri-devel
off^ has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
gouchi has joined #dri-devel
lemonzest has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
alyssa has joined #dri-devel
<alyssa> graphitemaster: bad bad bad bad
alyssa has left #dri-devel [#dri-devel]
alyssa has joined #dri-devel
<alyssa> On Mali, xfb and gs are both emulated in software, so that's just 2x the emulation for probably-even-worse-than-2x the slow :)
<graphitemaster> how do you see that message when you weren't here
<graphitemaster> stalkin' dri-devel
<alyssa> channel's publicly logged \s/
<alyssa> I mean. Psychic?
<pixelcluster> set up an irc bouncer
<graphitemaster> yo dawd i herd u like xfb so we put xfb in your xfb
<alyssa> truly
<graphitemaster> maybe hardware should stop emulating behavior and start implementing hardware to do it native
<graphitemaster> has anyone thunk of that xd
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
<alyssa> or we could just get rid of xfb and gs
<alyssa> That was Apple's approach, seemed to work well for em
<graphitemaster> Apple always gets rid of things before people want them to be rid of though.
<graphitemaster> I for one still want the 3.5mm jack and opengl :(
alyssa has left #dri-devel [#dri-devel]
kts has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
<abhinav__> javierm robclark isnt this the same warning as https://gitlab.freedesktop.org/drm/msm/-/issues/13 . We tried one solution from depthcharge and that didnt work. Now, we are still awaiting some guidance from clk team on whats missing, once a fix is posted on that one, we can re-test this use-case
<abhinav__> till then we have to boot with clk_ignore_unused pd_ignore_unused
<javierm> abhinav__: I think is the same issue yes, although I've CONFIG_PANEL_EDP=y in my config
<javierm> abhinav__: ah, we were wondering with robclark whether deptcharge gated the clocks or not. I see your comment about it https://gitlab.freedesktop.org/drm/msm/-/issues/13#note_1459272
rasterman has joined #dri-devel
lemonzest has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<robclark> javierm: hmm, one thing worth trying is DRM_MSM=m in case you have some weird probe order issue? (Although I'd have thought we'd be getting a lot more issues if that was the case)
<javierm> robclark: yes, I actually tried that and didn't work even with the config where display worked
<javierm> I also wanted to look at that issue but got dragged by the first one first
<robclark> ahh, ok.. then I think that points more towards _something_ missing.. but idk what
<javierm> robclark: yeah, me neither. I'll just use your known config and move on :)
<robclark> my config should at least more or less have everything that fedora needs enabled ;-)
<javierm> robclark: actually fedora as mentioned works out-of-the-box. At least with latest rawhide
<robclark> ahh, cool.. I didn't actually try distro kernel
<javierm> robclark: yes. I just usually don't want to use the fedora config since it builds the world as a module
<javierm> robclark: it would be great to have a make localsysfsconfig or something where automagically could figure out the kconfig symbols to be enabled depending on the devices present in sysfs
<robclark> heh, yeah
<robclark> I wish there was a good way to generate a config from the dtb, to be honest
<javierm> robclark: I guess you could get a good heuristic by looking at all present compatible strings, matching those with a struct of_device_id entries, then getting the files from there and the symbols from makefile
<javierm> but yes, a dtb -> .config would be a great thing to have
<javierm> robclark: in a way I miss the armv7 defconfig times where you could have a defconfig for a single machine in the kernel repo
<robclark> yeah
<robclark> maybe if there was a special macro type thing to declare the `struct of_device_id` array so you could more programatically build up the table of module to compat stings?
<javierm> robclark: if is built as a module is easy because the modules have that info as module aliases
<javierm> the problem is when is built-in
<robclark> or maybe just put compat strings in kconfig and generate at build time the table that gets linked into the final img or .ko?
gouchi has quit [Remote host closed the connection]
<javierm> robclark: that's a good idea
dviola has quit [Quit: WeeChat 3.6]
Duke`` has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
jewins has joined #dri-devel
<Frogging101> Does anyone have any theories about what might cause an application using VK_PRESENT_MODE_FIFO_KHR (waits for vblank) to tear, but only in windowed mode and only when near the window is near the top of the screen?
<Frogging101> This is on kwin with the compositor disabled
sdutt has joined #dri-devel
<Frogging101> Just wondering whether I should look at kwin, Xorg, or something else
<Frogging101> And this happens with other applications too.
<Frogging101> Including if I run mpv with opengl and swapinterval=1
fodasso has joined #dri-devel
<fodasso> Hello. I'm using Nouveau on a musl system with my RTX 2060. It hangs after several seconds/minutes of gameplay in a 3D game. It usually goes back to normal after some time (again, some seconds/minutes). Is it a known issue?
<fodasso> BTW, I'm running Gentoo
pcercuei has quit [Quit: dodo]
apinheiro has joined #dri-devel
<Frogging101> fodasso: Anything in dmesg?
<Frogging101> I can't really help because I don't have nvidia hardware but it's a good place to start
Wally has joined #dri-devel
Wally has quit [Remote host closed the connection]
Wally has joined #dri-devel
<Wally> Is the liscence header at drivers/gpu/drm/vgmem/Makefile BS?
Wally` has joined #dri-devel
Wally has quit [Read error: Connection reset by peer]
agx has quit [Read error: Connection reset by peer]
toolchains has joined #dri-devel
agx has joined #dri-devel
Wally` is now known as Wally
tanty has joined #dri-devel
Lyude has quit [Quit: Bouncer restarting]
Lyude has joined #dri-devel
Lyude has quit []
Lyude has joined #dri-devel
toolchains has quit [Read error: Connection timed out]
apinheiro has quit [Quit: Leaving]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]