--- Log opened Mon Feb 27 00:00:16 2023 --- Day changed Mon Feb 27 2023 00:00 -!- nchery [~nchery@134.134.139.80] has joined #intel-gfx 00:00 -!- nchery [~nchery@134.134.139.80] has joined #intel-3d 00:00 -!- nchery [~nchery@134.134.139.80] has joined #dri-devel 00:11 #radeon: < pixelcluster> cheako: you should initialize i to 0, your for loop should look like for(int i = 0; ... 00:14 #radeon: < cheako> thx 00:14 #radeon: < cheako> I'm unable to locate these libraries: `-- Could NOT find AGS (missing: AGS_INCLUDE_DIR) and Could NOT find Detours (missing: Detours_LIBRARY Detours_INCLUDE_DIR)` 00:18 -!- a-865 [~fmcz@24.50.25.175] has quit [Quit: ChatZilla 0.15 [SeaMonkey 2.53.15/20230108172623]] 00:22 #radeon: < cheako> Does ne1 write it like this, or just "NO". `for (int i = 0; i < fenceCount; std::cerr << ", ", i++) { std::cerr << pFences[i]; }` 00:22 #radeon: < HdkR> no 00:22 #radeon: < cheako> I've installed `libags-dev` and that didn't fix anything. 00:24 -!- BCMM [~BCMM@00026736.user.oftc.net] has quit [Quit: Konversation terminated!] 00:29 -!- a-865 [~fmcz@24.50.25.175] has joined #dri-devel 00:29 #radeon: < cheako> The build instructions say to run `make -j4` or `cmake --build` and neither works. https://www.irccloud.com/pastebin/FHMOdaTf/ 00:39 -!- mowcat [~mowcat@2a00:23c5:d190:1901:f22f:74ff:fe77:1e1c] has quit [Remote host closed the connection] 00:39 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has quit [Quit: dodo] 00:39 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has quit [Quit: dodo] 00:43 #radeon: < Venemo> cheako: if you haven't tried that yet, another thing you could try is Wayland vs Xorg or simply switching to a different desktop environment to rule out a bug with that. 00:46 #radeon: < cheako> That was one of the first things, what happened was those options were worse for other reasons. I don't remember if I used them long enough to see if they were ffected but I assume they were as I did switch back. 00:52 -!- Company [~Company@ip1f1264d8.dynamic.kabel-deutschland.de] has quit [Quit: Leaving] 00:52 -!- Company [~Company@ip1f1264d8.dynamic.kabel-deutschland.de] has quit [Quit: Leaving] 01:09 -!- arsenm1 [~Adium@69.80.24.243] has quit [] 01:13 -!- yuq825 [~yuq@180.152.11.27] has joined #lima 01:13 -!- yuq825 [~yuq@180.152.11.27] has joined #dri-devel 01:18 -!- KnM [~mdnavare@c-73-157-143-109.hsd1.or.comcast.net] has joined #intel-gfx 01:27 -!- co1umbarius [~columbari@i5387A694.versanet.de] has joined #dri-devel 01:27 -!- co1umbarius [~columbari@i5387A694.versanet.de] has joined #wayland 01:28 -!- columbarius [~columbari@i5387A69F.versanet.de] has quit [Ping timeout: 480 seconds] 01:28 -!- columbarius [~columbari@i5387A69F.versanet.de] has quit [Ping timeout: 480 seconds] 01:33 #dri-devel: < cmarcelo> what is virpipe? 01:35 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has joined #dri-devel 01:36 -!- scrumplex_ [~quassel@pd9fcec2b.dip0.t-ipconnect.de] has joined #freedesktop 01:37 -!- scrumplex [~quassel@pd9fce9c5.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 01:38 #dri-devel: < alyssa> iirc virgl on llvmpipe 01:38 #dri-devel: < alyssa> cmarcelo: 01:40 #dri-devel: < airlied> nope 01:40 #dri-devel: < airlied> it's virgl over a pipe 01:41 #dri-devel: < airlied> using drisw 01:43 #dri-devel: < alyssa> wild 01:43 #dri-devel: < cmarcelo> so, my undestanding is virgl is "OpenGL API that goes through the virtio gpu interface, relies on having something on the other side". so virpipe simulates the other side with LLVMpipe, or some other thing? 01:44 #dri-devel: < cmarcelo> (regular "other side" for virgl is the virgilrenderer) 01:45 #dri-devel: < alyssa> the virpipe-on-gl job is tagged as mesa-swrast so I assume so 01:45 -!- julio7359 [~julio7359@75.172.139.251] has quit [Remote host closed the connection] 01:45 #dri-devel: < airlied> cmarcelo: yeah virglrenderer has a unix socket based server 01:45 #dri-devel: < airlied> that is used for testing 01:45 #dri-devel: < airlied> and virpipe connects to that 01:46 #dri-devel: < alyssa> at any rate, the fails from the virpipe-on-gl job for scoped_barrier seem the same as the llvmpipe ones, so.. yeah 01:46 #dri-devel: < alyssa> i expect if you fix llvmpipe the virpipe fails goes away too 01:46 #dri-devel: < airlied> but yeah in CI it'll be llvmpipe in the end anyways 01:49 -!- camus [~Instantbi@58.246.136.202] has joined #lima 01:49 -!- camus [~Instantbi@58.246.136.202] has joined #dri-devel 01:59 #dri-devel: < cmarcelo> alyssa: yes, I'm guessing would be the same 02:01 #dri-devel: < DavidHeidelberg[m]> alyssa: mesa-swrast tag meaning is limited to the more powerful runners (more expensive) 02:02 #dri-devel: < alyssa> ah 02:02 #dri-devel: < alyssa> also why am i thinking about ci on a sunday 02:02 #dri-devel: < alyssa> ("to avoid thinking about your homework on a sunday" "ah yeah that'll due it") 02:02 #dri-devel: < DavidHeidelberg[m]> ... sadistic feelings? 02:02 #dri-devel: < cmarcelo> airlied: I'm likely missing something here: gallium driver virgl ~~~> unix socket bypass ~~~> virglrenderer, where do we draw virpipe? (I thought it would replace virglrenderer, but seems... not?) 02:03 #dri-devel: * DavidHeidelberg[m] looking forward to `venus -> zink` 02:03 #dri-devel: < DavidHeidelberg[m]> instead of virgl and virpipe 02:04 #dri-devel: < airlied> cmarcelo: no virpipe is just the drisw name for the gallium driver virgl bit 02:04 #dri-devel: < airlied> since we have multiple drisw drivers and need names to pick between them, llvmpipe, softpipe, virpipe 02:09 #dri-devel: < cmarcelo> let me try again, in the CI: gallium driver virgl ~~~> dri, but we pick drisw [virpipe variant] ~~~> unix socket bypass ~~~> virglrendered, which uses OpenGL ~~~> LLVMPIPE! 02:10 #dri-devel: < cmarcelo> airlied: ^ 02:14 #dri-devel: < airlied> yes that is about right 02:15 #dri-devel: < alyssa> man i'm looking forward to the scoped_barrier only future 02:15 #dri-devel: < alyssa> I assume anyway that is the end game of this series 02:15 #dri-devel: < alyssa> setting use_scoped_barrier for every backend, and then removing the option and memory_barrier_* intrinsics altogether 02:18 #dri-devel: < cmarcelo> alyssa: yeah, that's the end game 02:18 #dri-devel: < cmarcelo> we have a few steps to go though 02:19 #dri-devel: < cmarcelo> i.e. I don't plan to do everything in this particular MR 02:20 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has quit [Ping timeout: 480 seconds] 02:20 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has joined #dri-devel 02:21 -!- oneforall2 [~guru@S0106ec086bc3574f.mh.shawcable.net] has quit [Remote host closed the connection] 02:22 -!- oneforall2 [~guru@S0106ec086bc3574f.mh.shawcable.net] has joined #dri-devel 02:24 #dri-devel: < alyssa> yeah, for sure 02:24 #dri-devel: < alyssa> i'll write the {midgard,bifrost,agx} patches of course 02:26 #dri-devel: < alyssa> Nominally scoped_barrier should already work for bifrost 02:26 #dri-devel: < alyssa> since I hit it with OpenCL 02:28 #dri-devel: < alyssa> cmarcelo: ooh, and then renaming scoped_barrier -> barrier since it'll be the only one 02:29 -!- mmu_man [~revol@82-65-227-82.subs.proxad.net] has quit [Ping timeout: 480 seconds] 02:36 -!- caveman [~caveman@0002bdf0.user.oftc.net] has joined #wayland 02:50 #wayland: < wlb> wayland Issue #359 closed \o/ (Stylus tracking suddenly out of calibration https://gitlab.freedesktop.org/wayland/wayland/-/issues/359) 02:53 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has quit [Ping timeout: 480 seconds] 02:53 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has quit [Ping timeout: 480 seconds] 02:55 #dri-devel: < jenatali> And hope nobody is rebasing a multi-year-old change that references barrier 02:56 #dri-devel: < alyssa> jenatali: rebase conflicts make you stronger? :p 02:56 -!- aravind [~aravind@192.55.54.49] has joined #intel-gfx 02:56 -!- aravind [~aravind@192.55.54.49] has joined #dri-devel 02:57 -!- gtristan [~tristan@223.38.36.251] has joined #freedesktop 02:57 #dri-devel: < jenatali> It's one thing if it doesn't build but that conflict would be tricky 03:01 #dri-devel: < alyssa> jenatali: It wouldn't build 03:01 #dri-devel: < alyssa> there's not currently an intrinsic_barrier is there? 03:02 #dri-devel: < jenatali> Oh I thought there was 03:02 #dri-devel: < jenatali> Nevermind 03:15 -!- cool110 [~mark@0002e01f.user.oftc.net] has quit [Remote host closed the connection] 03:22 -!- bmodem [~Thunderbi@134.134.139.87] has joined #intel-gfx 03:22 -!- bmodem [~Thunderbi@134.134.139.87] has joined #dri-devel 03:26 -!- cool110 [~mark@0002e01f.user.oftc.net] has joined #wayland 03:28 #dri-devel: < hays> what is the most sensible way to get current screen resolution when still on the framebuffer (not in X) 03:35 #dri-devel: < airlied> hays: in what way, like inside an application? 03:36 #dri-devel: < hays> like when booting and showing a splash screen 03:36 -!- ximion [~ximion@ip-176-199-211-169.um44.pools.vodafone-ip.de] has quit [] 03:40 #dri-devel: < kode54> some clever emulator author suggested to me that the reason Ryujinx is so slow in some titles on ANV is because ANV is "still optimized for integrated graphics" 03:41 #dri-devel: < kode54> (not a Ryujinx dev, but a nosy dev of another project) 03:43 #dri-devel: < alyssa> kode54: wdym 03:43 -!- rsalvaterra_ [~quassel@a95-93-117-213.cpe.netcabo.pt] has joined #dri-devel 03:43 -!- rsalvaterra is now known as Guest6017 03:43 -!- Guest6017 is now known as Guest6018 03:43 -!- rsalvaterra_ is now known as rsalvaterra 03:44 #dri-devel: < kode54> Soup Odyssey slows to 10-20fps on some areas on an A770, hitting 100% FIFO utilization and maxing out the rendering cores 03:44 #dri-devel: < kode54> VBA-M dev Squall Leonhart popped into my bug report to Ryujinx to say that the ANV driver isn't optimized for dedicated GPUs yet 03:45 #dri-devel: < alyssa> oh, that I would believe. 03:45 #dri-devel: < kode54> it is an interesting point though 03:46 #dri-devel: < kode54> considering that in Windows, rather than Intel adapting their Iris drivers to Arc, they started over from scratch 03:46 -!- gtristan_ [~tristan@223.38.35.207] has joined #freedesktop 03:46 #dri-devel: < kode54> wonder if that would even be worth it for Linux 03:47 #dri-devel: < kode54> Xe DG1 may also benefit, since it's a dGPU of a different sort 03:47 #dri-devel: < kode54> but hell, that sounds like a nightmare, starting over 03:47 -!- Guest6018 [~quassel@a95-93-117-213.cpe.netcabo.pt] has quit [Ping timeout: 480 seconds] 03:48 #dri-devel: < alyssa> Not an Intel developer but rewriting ANV seems completely uncalled for 03:48 #dri-devel: < kode54> indeed 03:48 #dri-devel: < alyssa> I would be unsurprised if the Windows rewrite was due to politics and not perf 03:49 #dri-devel: < kode54> maybe someone needs to buy zmike an Arc card 03:49 -!- gtristan [~tristan@223.38.36.251] has quit [Ping timeout: 480 seconds] 03:50 #dri-devel: < kode54> I didn't mean to imply that any of the existing code was bad, but it probably has choke points that uniquely affect dGPUs 03:50 #dri-devel: < kode54> maybe 03:51 #dri-devel: < kode54> I haven't profiled anything that does particularly bad to see where exactly it's choking 03:51 #dri-devel: < alyssa> I stand by ^ 03:51 #dri-devel: < kode54> politics, indeed 03:51 #dri-devel: < alyssa> It is (almost) never warranted to rewrite mature codebases from scratch 03:52 #dri-devel: < kode54> I wasn't suggesting a rewrite either 03:52 #dri-devel: < alyssa> so if a corporate team does so anyway 03:52 #dri-devel: < alyssa> often there are political reasons :p 03:52 #dri-devel: < kode54> yeah 03:52 #dri-devel: < airlied> also not sure they rewrote their windows drivers from scratch 03:52 #dri-devel: < kode54> they certainly ripped out the DX9-11 parts 03:52 #dri-devel: < kode54> or made them worse 03:53 #dri-devel: < airlied> those are just pieces of the driver stack though 03:53 #dri-devel: < airlied> I think their windows d3d12/vulkan drivers might have a lot of common code 03:53 #dri-devel: < kode54> probably 03:53 #dri-devel: < airlied> and their media stack looks like they forked it inside itself in a horrible nightmare of code duplication 03:53 #dri-devel: < kode54> it's a right mess 03:54 #dri-devel: < kode54> and they've got the hugest driver package of any vendor right now 03:54 #dri-devel: < alyssa> airlied: why are we not shipping anv on Windows again 03:54 #dri-devel: < airlied> alyssa: politics :-P 03:54 #dri-devel: < alyssa> (-: 03:54 #dri-devel: < kode54> of course it is 03:55 -!- vyryls [~joel@gun3506012.lnk.telstra.net] has joined #wayland 03:55 #dri-devel: < alyssa> oh hey I fixed buffer textures on asahi 03:55 #dri-devel: < kode54> neat 03:55 #dri-devel: < alyssa> they were broken for like 2 months 03:55 #dri-devel: < kode54> oh wow 03:55 #dri-devel: < cmarcelo> kode54: I'm not particularly versed on the details of local memory, but: our kernel driver team is working on a new version of the driver https://patchwork.freedesktop.org/series/112188/ (there's a corresponding MR for anv to interface with that) that I expect will get us some improvements in that area. 03:55 #dri-devel: < alyssa> in agx/next I mean 03:55 #dri-devel: < alyssa> never opend an MR because of said broken 03:55 #dri-devel: < kode54> yeah, the Xe KMD 03:55 #dri-devel: < kode54> I was following that loosely 03:56 #dri-devel: < kode54> I'd definitely be open to actually shoving that into my system when it comes time to test it 03:56 #dri-devel: < kode54> assuming it's in a relatively ready state 03:56 #dri-devel: < kode54> I've already been running 6.2 since the first RC, building it myself 03:57 #dri-devel: < kode54> and running mesa-git with the intel-clc function enabled, also building that myself 03:57 #dri-devel: < kode54> well, with PKGBUILDs handily supplied by TkG 03:58 #dri-devel: < cmarcelo> kode54: what is the number for the gitlab issue you mentioned above? 03:59 #dri-devel: < kode54> oh, sorry, I need to report it on mesa tracker too 03:59 #dri-devel: < kode54> I initially reported it to Ryujinx, and forgot to post the Mesa issue 03:59 #dri-devel: < cmarcelo> ok 03:59 #dri-devel: < kode54> I'll grab the Ryujinx issue and link it on Mesa's tracker 03:59 #dri-devel: < kode54> I'll try to be a bit thorough with what I write 04:00 -!- sparky4 [~sparky4@hutcheson-192.resnet.latech.edu] has quit [Remote host closed the connection] 04:00 #dri-devel: < kode54> oh 04:00 #dri-devel: < kode54> someone else already posted an issue 04:00 #dri-devel: < kode54> I'll reply to it and track it 04:00 -!- alyssa [~alyssa@rosenzweig.io] has quit [Quit: leaving] 04:01 #dri-devel: < kode54> oh 04:02 #dri-devel: < kode54> it was a different game I found by chance 04:02 -!- Zopolis4 [uid504804@id-504804.ilkley.irccloud.com] has joined #dri-devel 04:02 #dri-devel: < kode54> I'll reply to the issue nonetheless 04:05 -!- vyryls [~joel@gun3506012.lnk.telstra.net] has quit [Quit: WeeChat 3.8] 04:06 #dri-devel: < kode54> https://gitlab.freedesktop.org/mesa/mesa/-/issues/8375 issue just opened a day ago about various titles either underperforming compared to Windows or outright failing to run 04:07 -!- neobrain [~neobrain@noether.physik.uni-erlangen.de] has quit [Ping timeout: 480 seconds] 04:07 -!- neobrain [~neobrain@noether.physik.uni-erlangen.de] has quit [Ping timeout: 480 seconds] 04:07 -!- neobrain [~neobrain@noether.physik.uni-erlangen.de] has quit [Ping timeout: 480 seconds] 04:10 #dri-devel: < cmarcelo> kode54: thanks for linking 04:13 -!- pabs [~pabs@pabs.user.oftc.net] has quit [Remote host closed the connection] 04:13 -!- pabs [~pabs@pabs.user.oftc.net] has quit [Remote host closed the connection] 04:17 #dri-devel: < kode54> funny issue one of those games not mentioned, but I know it's a performance issue nonetheless 04:17 #dri-devel: < kode54> Destiny 2 underperforms from what I've heard 04:17 #dri-devel: < kode54> but they can't just make it use DXVK on Windows 04:18 #dri-devel: < kode54> the game's stupid ass anticheat system will just ban people for that 04:18 #dri-devel: < kode54> I can't believe that PVP is a big enough proportion of their user base to even warrant a fricking anticheat system 04:19 #dri-devel: < kode54> then again, they also have a huge number of players who will create new characters and just camp out in the intro stages to powerlevel 04:19 #dri-devel: < kode54> that must be awfully boring 04:19 #dri-devel: < kode54> I want that game as a max 4 players game like Borderlands 04:20 #dri-devel: < kode54> screw this MMO with gacha elements cash cow crap 04:25 -!- pabs [~pabs@pabs.user.oftc.net] has joined #nouveau 04:25 -!- pabs [~pabs@pabs.user.oftc.net] has joined #intel-gfx 04:26 -!- aravind [~aravind@192.55.54.49] has quit [Ping timeout: 480 seconds] 04:26 -!- aravind [~aravind@192.55.54.49] has quit [Ping timeout: 480 seconds] 04:30 -!- dviola [~diego@179.235.30.21] has joined #intel-gfx 04:30 -!- dviola [~diego@179.235.30.21] has joined #intel-3d 04:30 -!- dviola [~diego@179.235.30.21] has joined #radeon 04:30 -!- dviola [~diego@179.235.30.21] has joined #nouveau 04:30 -!- dviola [~diego@179.235.30.21] has joined #dri-devel 04:32 -!- Leopold_ [~quassel@4JHAAACCZ.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 04:32 -!- Leopold_ [~quassel@4JHAAACCZ.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 04:32 -!- Leopold_ [~quassel@4JHAAACCZ.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 04:32 -!- Leopold_ [~quassel@4JHAAACCZ.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 04:32 -!- Leopold_ [~quassel@4JHAAACCZ.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 04:32 -!- Leopold_ [~quassel@4JHAAACCZ.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 04:32 -!- Leopold_ [~quassel@4JHAAACCZ.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 04:32 -!- Leopold_ [~quassel@4JHAAACCZ.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 04:32 -!- Leopold_ [~quassel@4JHAAACCZ.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 04:35 -!- JerryXiao [~JerryXiao@0002c7a5.user.oftc.net] has quit [Quit: Bye] 04:37 -!- JerryXiao [~JerryXiao@0002c7a5.user.oftc.net] has joined #radeon 04:43 -!- lynxis [~lunarius@000127af.user.oftc.net] has quit [Remote host closed the connection] 04:44 -!- lynxis [~lunarius@194.150.169.150] has joined #freedesktop 04:50 -!- ybogdano1 [~ybogdano@50.39.173.13] has quit [] 04:50 -!- ybogdano1 [~ybogdano@50.39.173.13] has quit [] 04:50 -!- ybogdano1 [~ybogdano@50.39.173.13] has quit [] 04:50 -!- ybogdano1 [~ybogdano@50.39.173.13] has quit [] 04:50 -!- ybogdano1 [~ybogdano@50.39.173.13] has quit [] 04:50 -!- ybogdano [~ybogdano@50.39.173.13] has joined #freedesktop 04:50 -!- ybogdano [~ybogdano@50.39.173.13] has joined #intel-gfx 04:50 -!- ybogdano [~ybogdano@50.39.173.13] has joined #intel-3d 04:50 -!- ybogdano [~ybogdano@50.39.173.13] has joined #dri-devel 04:50 -!- ybogdano [~ybogdano@50.39.173.13] has joined #wayland 04:51 -!- ybogdano [~ybogdano@50.39.173.13] has quit [Remote host closed the connection] 04:51 -!- ybogdano [~ybogdano@50.39.173.13] has quit [Remote host closed the connection] 04:51 -!- ybogdano [~ybogdano@50.39.173.13] has quit [Remote host closed the connection] 04:51 -!- ybogdano [~ybogdano@50.39.173.13] has quit [Remote host closed the connection] 04:51 -!- ybogdano [~ybogdano@50.39.173.13] has quit [Remote host closed the connection] 04:52 -!- ybogdano [~ybogdano@50.39.173.13] has joined #freedesktop 04:52 -!- ybogdano [~ybogdano@50.39.173.13] has joined #intel-gfx 04:52 -!- ybogdano [~ybogdano@50.39.173.13] has joined #intel-3d 04:52 -!- ybogdano [~ybogdano@50.39.173.13] has joined #dri-devel 04:52 -!- ybogdano [~ybogdano@50.39.173.13] has joined #wayland 05:01 -!- swatish2 [~swatish2@134.134.139.80] has joined #intel-gfx 05:16 -!- floof58 is now known as Guest6024 05:16 -!- floof58 is now known as Guest6024 05:16 -!- floof58 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has joined #radeon 05:16 -!- floof58 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has joined #wayland 05:19 -!- pabs [~pabs@pabs.user.oftc.net] has quit [Remote host closed the connection] 05:19 -!- pabs [~pabs@pabs.user.oftc.net] has quit [Remote host closed the connection] 05:19 -!- pabs [~pabs@pabs.user.oftc.net] has joined #nouveau 05:19 -!- pabs [~pabs@pabs.user.oftc.net] has joined #intel-gfx 05:21 -!- Guest6024 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has quit [Ping timeout: 480 seconds] 05:21 -!- Guest6024 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has quit [Ping timeout: 480 seconds] 05:22 -!- aravind [~aravind@134.134.137.86] has joined #intel-gfx 05:22 -!- aravind [~aravind@134.134.137.86] has joined #dri-devel 05:25 -!- JohnDoe_71Rus [~CLDX@80.78.195.138] has joined #radeon 05:32 -!- gtristan_ [~tristan@223.38.35.207] has quit [Ping timeout: 480 seconds] 05:36 #freedesktop: < thaytan> mupuf, if they've built a bot that registers accounts and spams automatically I'm not sure they'll lose interest. It'll just keep plugging away 05:36 #freedesktop: < mupuf> thaytan: the account registration looks manual. There are many usernames that look like they just mashed the keys. Something like asdasdasdfasd 05:37 #freedesktop: < thaytan> Oh good. fingers crossed then 05:37 -!- hogander [~jhogande@134.191.220.81] has joined #intel-gfx 05:38 #freedesktop: < mupuf> Here is an actual one "ututyuyt dsgsdg" :D 05:39 #freedesktop: < thaytan> yeah, I reported that one earlier 05:39 #freedesktop: < mupuf> and it's gone! 05:39 -!- kzd [~kzd@static-198-54-130-84.cust.tzulo.com] has quit [Quit: kzd] 05:39 -!- kzd [~kzd@static-198-54-130-84.cust.tzulo.com] has quit [Quit: kzd] 05:49 -!- pallavim [~pallavim@134.134.139.80] has joined #intel-gfx 05:49 -!- pallavim [~pallavim@134.134.139.80] has joined #dri-devel 06:02 -!- xroumegue [~roumegue@2a01:cb1d:b1:7700:a8aa:651a:6e0f:606] has quit [Ping timeout: 480 seconds] 06:11 -!- xroumegue [~roumegue@2a01:cb1d:b1:7700:354e:d2b7:ad33:ccc8] has joined #dri-devel 06:15 -!- itoral [~itoral@100.49.60.213.dynamic.reverse-mundo-r.com] has joined #dri-devel 06:23 -!- pallavim [~pallavim@134.134.139.80] has quit [Ping timeout: 480 seconds] 06:23 -!- pallavim [~pallavim@134.134.139.80] has quit [Ping timeout: 480 seconds] 06:26 -!- ybogdano is now known as Guest6029 06:26 -!- ybogdano is now known as Guest6029 06:26 -!- ybogdano is now known as Guest6029 06:26 -!- ybogdano is now known as Guest6029 06:26 -!- ybogdano is now known as Guest6029 06:26 -!- ybogdano [~ybogdano@50.39.173.13] has joined #freedesktop 06:26 -!- ybogdano [~ybogdano@50.39.173.13] has joined #intel-gfx 06:26 -!- ybogdano [~ybogdano@50.39.173.13] has joined #intel-3d 06:26 -!- ybogdano [~ybogdano@50.39.173.13] has joined #dri-devel 06:26 -!- ybogdano [~ybogdano@50.39.173.13] has joined #wayland 06:32 -!- Guest6029 [~ybogdano@50.39.173.13] has quit [Ping timeout: 480 seconds] 06:32 -!- Guest6029 [~ybogdano@50.39.173.13] has quit [Ping timeout: 480 seconds] 06:32 -!- Guest6029 [~ybogdano@50.39.173.13] has quit [Ping timeout: 480 seconds] 06:32 -!- Guest6029 [~ybogdano@50.39.173.13] has quit [Ping timeout: 480 seconds] 06:32 -!- Guest6029 [~ybogdano@50.39.173.13] has quit [Ping timeout: 480 seconds] 06:41 -!- jernej [~jernej@0002b859.user.oftc.net] has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net] 06:41 -!- jernej [~jernej@0002b859.user.oftc.net] has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net] 06:41 -!- jernej [~jernej@0002b859.user.oftc.net] has joined #dri-devel 06:41 -!- jernej [~jernej@0002b859.user.oftc.net] has joined #lima 06:43 -!- nnm_ [~nnm@nnm.powered.by.lunarbnc.net] has joined #wayland 06:43 -!- nnm_ [~nnm@nnm.powered.by.lunarbnc.net] has joined #nouveau 06:43 -!- nnm_ [~nnm@nnm.powered.by.lunarbnc.net] has quit [Remote host closed the connection] 06:43 -!- nnm_ [~nnm@nnm.powered.by.lunarbnc.net] has quit [Remote host closed the connection] 06:45 -!- nnm_ [~nnm@nnm.powered.by.lunarbnc.net] has joined #wayland 06:45 -!- nnm_ [~nnm@nnm.powered.by.lunarbnc.net] has joined #nouveau 06:46 -!- nnm_ [~nnm@nnm.powered.by.lunarbnc.net] has quit [] 06:46 -!- nnm_ [~nnm@nnm.powered.by.lunarbnc.net] has quit [] 06:47 -!- fab [~fab@bellet.info] has joined #dri-devel 06:47 -!- jernej [~jernej@0002b859.user.oftc.net] has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net] 06:47 -!- jernej [~jernej@0002b859.user.oftc.net] has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net] 06:48 -!- jernej [~jernej@0002b859.user.oftc.net] has joined #dri-devel 06:48 -!- jernej [~jernej@0002b859.user.oftc.net] has joined #lima 06:48 -!- jernej [~jernej@0002b859.user.oftc.net] has quit [Read error: Connection reset by peer] 06:48 -!- jernej [~jernej@0002b859.user.oftc.net] has quit [Read error: Connection reset by peer] 06:49 -!- nnm_ [~nnm@nnm.powered.by.lunarbnc.net] has joined #wayland 06:49 -!- nnm_ [~nnm@nnm.powered.by.lunarbnc.net] has joined #nouveau 06:49 -!- jernej [~jernej@jernej.powered.by.lunarbnc.net] has joined #dri-devel 06:49 -!- jernej [~jernej@jernej.powered.by.lunarbnc.net] has joined #lima 06:50 -!- nnm [~nnm@nnm.powered.by.lunarbnc.net] has quit [Ping timeout: 480 seconds] 06:50 -!- nnm [~nnm@nnm.powered.by.lunarbnc.net] has quit [Ping timeout: 480 seconds] 06:53 -!- bgs [~bgs@212-85-160-171.dynamic.telemach.net] has joined #dri-devel 06:56 -!- slisovsk [~slisovsk@134.134.139.70] has joined #intel-gfx 06:59 -!- JohnDoe_71Rus [~CLDX@80.78.195.138] has quit [] 06:59 -!- grillo_0 [~grillo@37.218.246.133] has quit [Quit: Ping timeout (120 seconds)] 06:59 -!- grillo_0 [~grillo@37.218.246.133] has joined #dri-devel 06:59 -!- ccr_ [ccr@tnsp.org] has joined #dri-devel 06:59 -!- ccr [ccr@tnsp.org] has quit [Read error: Connection reset by peer] 07:00 -!- JohnDoe_71Rus [~CLDX@80.78.195.138] has joined #radeon 07:00 -!- ryanpavlik [~ryanpavli@gyros.collabora.co.uk] has quit [] 07:00 -!- ryanpavlik [~ryanpavli@gyros.collabora.co.uk] has joined #freedesktop 07:02 -!- hardening [~quassel@arennes-655-1-19-105.w109-218.abo.wanadoo.fr] has joined #wayland 07:02 -!- imre [~imre@213-243-176-34.bb.dnainternet.fi] has quit [Remote host closed the connection] 07:02 -!- imre [~imre@213-243-176-34.bb.dnainternet.fi] has quit [Remote host closed the connection] 07:02 -!- imre [~imre@213-243-176-34.bb.dnainternet.fi] has joined #intel-gfx 07:02 -!- imre [~imre@213-243-176-34.bb.dnainternet.fi] has joined #dri-devel 07:03 -!- Remco_ [~remco@r3m.co] has joined #radeon 07:03 -!- Remco [~remco@r3m.co] has quit [Read error: Connection reset by peer] 07:03 -!- indy [~indy@0001c91b.user.oftc.net] has quit [Ping timeout: 480 seconds] 07:05 -!- eloy__ [~quassel@eloydegen.com] has quit [Ping timeout: 480 seconds] 07:06 -!- eloy_ [~quassel@eloydegen.com] has joined #dri-devel 07:06 -!- milek7_ [~quassel@milek7.pl] has quit [Ping timeout: 480 seconds] 07:06 -!- milek7_ [~quassel@milek7.pl] has quit [Ping timeout: 480 seconds] 07:06 -!- milek7 [~quassel@milek7.pl] has joined #dri-devel 07:06 -!- milek7 [~quassel@milek7.pl] has joined #d3d9 07:09 -!- pjakobsson [~pjakobsso@81-226-149-122-no518.tbcn.telia.com] has quit [Remote host closed the connection] 07:09 -!- pjakobsson [~pjakobsso@81-226-149-122-no518.tbcn.telia.com] has quit [Remote host closed the connection] 07:09 -!- pjakobsson [~pjakobsso@81-226-149-122-no518.tbcn.telia.com] has quit [Remote host closed the connection] 07:09 -!- pjakobsson [~pjakobsso@81-226-149-122-no518.tbcn.telia.com] has quit [Remote host closed the connection] 07:09 -!- pjakobsson [~pjakobsso@81-226-149-122-no518.tbcn.telia.com] has quit [Remote host closed the connection] 07:10 -!- indy [~indy@0001c91b.user.oftc.net] has joined #nouveau 07:11 -!- mmind00 [~mmind00@gloria.sntech.de] has quit [Ping timeout: 480 seconds] 07:11 -!- mmind00 [~mmind00@gloria.sntech.de] has quit [Ping timeout: 480 seconds] 07:11 -!- mmind00 [~mmind00@gloria.sntech.de] has joined #lima 07:11 -!- mmind00 [~mmind00@gloria.sntech.de] has joined #dri-devel 07:15 -!- gtristan [~tristan@223.38.35.120] has joined #freedesktop 07:20 -!- ccr_ [ccr@tnsp.org] has quit [] 07:20 -!- ccr [ccr@tnsp.org] has joined #dri-devel 07:20 -!- Deluxef [~Deluxe@212.4.150.151] has joined #radeon 07:21 -!- miracolix [~snuckls@p4fd1a6ea.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 07:32 -!- mtretter [~mtretter@office.nat.stw.pengutronix.de] has joined #wayland 07:33 -!- mtretter is now known as mtr[stw] 07:33 -!- mtr[stw] [~mtretter@office.nat.stw.pengutronix.de] has quit [] 07:34 -!- alanc [~alanc@148.87.23.6] has quit [Remote host closed the connection] 07:34 -!- alanc [~alanc@148.87.23.6] has quit [Remote host closed the connection] 07:34 -!- alanc [~alanc@148.87.23.6] has joined #dri-devel 07:34 -!- alanc [~alanc@148.87.23.6] has joined #freedesktop 07:36 -!- Deluxef [~Deluxe@212.4.150.151] has quit [Remote host closed the connection] 07:38 -!- fab [~fab@bellet.info] has quit [Quit: fab] 07:38 -!- Deluxe [~Deluxe@212.4.150.151] has joined #radeon 07:40 -!- molinari [~molinari@176-151-233-216.abo.bbox.fr] has joined #wayland 07:42 -!- Jeremy_Rand_Talos [~Jeremy_Ra@4G4AACYBV.tor-irc.dnsbl.oftc.net] has quit [Remote host closed the connection] 07:42 -!- kts [~kts@103.73.237.109] has joined #dri-devel 07:42 -!- kts [~kts@103.73.237.109] has joined #intel-gfx 07:42 -!- kts [~kts@103.73.237.109] has joined #intel-3d 07:42 -!- kts [~kts@103.73.237.109] has joined #wayland 07:42 -!- Jeremy_Rand_Talos [~Jeremy_Ra@8L3AADI27.tor-irc.dnsbl.oftc.net] has joined #dri-devel 07:42 -!- rasterman [~rasterman@80.7.141.101] has joined #dri-devel 07:42 -!- rasterman [~rasterman@80.7.141.101] has joined #wayland 07:45 -!- ricotz [~ricotz@155.133.217.97] has joined #nouveau 07:46 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has joined #freedesktop 07:46 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has joined #dri-devel 07:46 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has joined #radeon 07:52 -!- jsa [~jsaarine@134.191.221.82] has joined #intel-gfx 08:01 -!- rv1sr [~rv1sr@0002da44.user.oftc.net] has joined #wayland 08:02 -!- kts [~kts@103.73.237.109] has quit [Quit: Konversation terminated!] 08:02 -!- kts [~kts@103.73.237.109] has quit [Quit: Konversation terminated!] 08:02 -!- kts [~kts@103.73.237.109] has quit [Quit: Konversation terminated!] 08:02 -!- kts [~kts@103.73.237.109] has quit [Quit: Konversation terminated!] 08:03 -!- sghuge [~sagar@134.134.137.86] has joined #intel-3d 08:03 -!- sghuge [~sagar@134.134.137.86] has joined #intel-gfx 08:03 -!- sghuge [~sagar@134.134.137.86] has joined #dri-devel 08:04 -!- jkrzyszt [~jkrzyszt@192.198.151.55] has joined #intel-gfx 08:04 -!- jkrzyszt [~jkrzyszt@192.198.151.55] has joined #dri-devel 08:05 -!- jkrzyszt [~jkrzyszt@192.198.151.55] has quit [Remote host closed the connection] 08:05 -!- jkrzyszt [~jkrzyszt@192.198.151.55] has quit [Remote host closed the connection] 08:06 -!- fab [~fab@134.214.236.142] has joined #dri-devel 08:07 -!- xmn [~xmn@cpe-72-225-198-203.nyc.res.rr.com] has quit [Ping timeout: 480 seconds] 08:09 #freedesktop: < bentiss> doing the gitlab 15.9.1 update in a bit 08:11 -!- jkrzyszt [~jkrzyszt@134.191.221.86] has joined #intel-gfx 08:11 -!- jkrzyszt [~jkrzyszt@134.191.221.86] has joined #dri-devel 08:13 -!- gtristan_ [~tristan@223.38.36.111] has joined #freedesktop 08:13 -!- gtristan [~tristan@223.38.35.120] has quit [Ping timeout: 480 seconds] 08:19 -!- pH5 [~pza@ptz.office.stw.pengutronix.de] has joined #dri-devel 08:19 -!- pH5 [~pza@ptz.office.stw.pengutronix.de] has joined #etnaviv 08:19 -!- pH5 [~pza@ptz.office.stw.pengutronix.de] has joined #wayland 08:21 -!- gtristan_ [~tristan@223.38.36.111] has quit [Ping timeout: 480 seconds] 08:28 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #wayland 08:28 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #radeon 08:28 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #nouveau 08:28 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #intel-gfx 08:28 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #intel-3d 08:28 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #freedesktop 08:28 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #dri-devel 08:29 -!- MajorBiscuit [~MajorBisc@c-001-027-039.client.tudelft.eduvpn.nl] has joined #dri-devel 08:29 -!- MajorBiscuit [~MajorBisc@c-001-027-039.client.tudelft.eduvpn.nl] has joined #freedesktop 08:29 -!- MajorBiscuit [~MajorBisc@c-001-027-039.client.tudelft.eduvpn.nl] has joined #intel-gfx 08:29 -!- MajorBiscuit [~MajorBisc@c-001-027-039.client.tudelft.eduvpn.nl] has joined #nouveau 08:29 -!- MajorBiscuit [~MajorBisc@c-001-027-039.client.tudelft.eduvpn.nl] has joined #radeon 08:29 -!- MajorBiscuit [~MajorBisc@c-001-027-039.client.tudelft.eduvpn.nl] has joined #wayland 08:33 -!- manuel1985 [~manuel198@62.99.131.178] has joined #wayland 08:34 #dri-devel: < hakzsam> daniels: hi, any news on the vesnu-lavapipe front? 08:35 #freedesktop: < bentiss> alright, this was done without any hiccups 08:36 #freedesktop: < bentiss> daniels: do we want to enable gitlab-sshd instead of openssh? https://docs.gitlab.com/ee/administration/operations/gitlab_sshd.html 08:36 #freedesktop: < bentiss> the only think that is different is "gitlab-sshd does not support SSH certificates." and I don't think we have that enabled for us, no? 08:39 -!- nyn [~UltimateN@2a02:8108:9440:24d0:2993:1842:4eb7:b61c] has quit [Ping timeout: 480 seconds] 08:40 -!- fab [~fab@134.214.236.142] has quit [Quit: fab] 08:41 -!- OftenTimeConsuming is now known as Guest6039 08:41 -!- OftenTimeConsuming is now known as Guest6039 08:41 -!- OftenTimeConsuming [~Username@0002ac9d.user.oftc.net] has joined #dri-devel 08:41 -!- OftenTimeConsuming [~Username@0002ac9d.user.oftc.net] has joined #nouveau 08:41 -!- ximion [~ximion@ip-176-199-211-169.um44.pools.vodafone-ip.de] has joined #freedesktop 08:42 -!- Guest6039 [~Username@0002ac9d.user.oftc.net] has quit [Remote host closed the connection] 08:42 -!- Guest6039 [~Username@0002ac9d.user.oftc.net] has quit [Remote host closed the connection] 08:42 -!- MrCooper [~MrCooper@00026873.user.oftc.net] has quit [Remote host closed the connection] 08:42 -!- MrCooper [~MrCooper@00026873.user.oftc.net] has quit [Remote host closed the connection] 08:42 -!- MrCooper [~MrCooper@00026873.user.oftc.net] has quit [Remote host closed the connection] 08:42 -!- MrCooper [~MrCooper@00026873.user.oftc.net] has quit [Remote host closed the connection] 08:43 -!- MrCooper [~MrCooper@2001:1620:4baa:0:a27b:b696:fef5:a239] has joined #radeon 08:43 -!- MrCooper [~MrCooper@2001:1620:4baa:0:a27b:b696:fef5:a239] has joined #dri-devel 08:43 -!- MrCooper [~MrCooper@2001:1620:4baa:0:a27b:b696:fef5:a239] has joined #wayland 08:43 -!- MrCooper [~MrCooper@2001:1620:4baa:0:a27b:b696:fef5:a239] has joined #freedesktop 08:43 -!- dcz_ [~dcz@78.48.144.251] has joined #wayland 08:46 -!- macromorgan is now known as Guest6040 08:46 -!- Guest6040 [~macromorg@2600:1700:fb0:1bcf:25:e62b:a760:ca36] has quit [Read error: Connection reset by peer] 08:47 -!- macromorgan [~macromorg@2600:1700:fb0:1bcf:e549:43b9:3d31:e282] has joined #dri-devel 08:47 -!- kxkamil [~kamilkon@134.191.220.81] has quit [] 08:47 -!- kxkamil [~kamilkon@134.191.220.81] has quit [] 08:47 -!- Supersaiyan_IV [~QAM@85.228.153.205] has joined #intel-gfx 08:47 -!- Supersaiyan_IV [~QAM@85.228.153.205] has joined #radeon 08:50 -!- kinkinkijkin [~kinkinkij@162.246.53.59] has joined #radeon 08:54 -!- lynxeye [~lynxeye@2a02:560:58a5:c300:20e1:7881:a58b:630d] has joined #etnaviv 08:54 -!- lynxeye [~lynxeye@2a02:560:58a5:c300:20e1:7881:a58b:630d] has joined #dri-devel 08:55 -!- macromorgan is now known as Guest6042 08:55 -!- macromorgan [~macromorg@76.244.6.13] has joined #dri-devel 08:57 -!- Guest6042 [~macromorg@2600:1700:fb0:1bcf:e549:43b9:3d31:e282] has quit [Ping timeout: 480 seconds] 08:57 -!- vliaskov [~vliaskov@dynamic-077-191-055-225.77.191.pool.telefonica.de] has joined #dri-devel 08:57 -!- vliaskov [~vliaskov@dynamic-077-191-055-225.77.191.pool.telefonica.de] has joined #nouveau 09:00 -!- srslypascal is now known as Guest6044 09:00 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has joined #dri-devel 09:01 -!- gtristan [~tristan@223.38.35.227] has joined #freedesktop 09:01 #freedesktop: < bentiss> mupuf: https://docs.gitlab.com/ee/user/admin_area/settings/email.html#custom-additional-text-in-deactivation-emails -> new thing that might be of interest for the deactivation email 09:01 -!- fab [~fab@gandi-2.bellet.info] has joined #dri-devel 09:01 -!- pochu [~pochu@87.red-88-30-59.staticip.rima-tde.net] has joined #wayland 09:01 -!- pochu [~pochu@87.red-88-30-59.staticip.rima-tde.net] has joined #dri-devel 09:02 -!- fab [~fab@gandi-2.bellet.info] has quit [] 09:02 -!- fab [~fab@gandi-2.bellet.info] has joined #dri-devel 09:03 -!- Guest6044 [~srslypasc@0002bff5.user.oftc.net] has quit [Ping timeout: 480 seconds] 09:05 -!- ximion [~ximion@ip-176-199-211-169.um44.pools.vodafone-ip.de] has quit [] 09:07 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has quit [Read error: No route to host] 09:07 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has joined #dri-devel 09:07 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has joined #intel-gfx 09:07 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has joined #nouveau 09:07 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has joined #radeon 09:07 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has joined #wayland 09:08 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has joined #dri-devel 09:28 -!- epoll [~epaul1@2400:4051:61:600:71b1:8db3:a107:d7a8] has quit [Ping timeout: 480 seconds] 09:32 -!- phasta [~phasta@82.207.245.25] has joined #dri-devel 09:32 -!- phasta [~phasta@82.207.245.25] has joined #nouveau 09:32 -!- phasta [~phasta@82.207.245.25] has joined #freedesktop 09:36 -!- neobrain [~neobrain@noether.physik.uni-erlangen.de] has joined #dri-devel 09:36 -!- neobrain [~neobrain@noether.physik.uni-erlangen.de] has joined #radeon 09:36 -!- neobrain [~neobrain@noether.physik.uni-erlangen.de] has joined #wayland 09:37 -!- epoll [~epaul1@2400:4051:61:600:bcb7:b69b:92e2:82ee] has joined #dri-devel 09:37 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has joined #etnaviv 09:37 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has joined #dri-devel 09:57 -!- jess [~jess@husky.lolnerd.net] has quit [Quit: Lost terminal] 10:03 -!- kxkamil [~kamilkon@134.191.220.81] has joined #intel-gfx 10:03 -!- kxkamil [~kamilkon@134.191.220.81] has joined #dri-devel 10:05 -!- nchery is now known as Guest6049 10:05 -!- nchery is now known as Guest6049 10:05 -!- nchery is now known as Guest6049 10:05 -!- nchery [~nchery@134.134.139.80] has joined #intel-gfx 10:05 -!- nchery [~nchery@134.134.139.80] has joined #intel-3d 10:05 -!- nchery [~nchery@134.134.139.80] has joined #dri-devel 10:06 -!- greenjustin__ [~greenjust@2620:0:1003:314:df6a:bf51:1814:2276] has quit [Remote host closed the connection] 10:11 -!- Guest6049 [~nchery@134.134.139.80] has quit [Ping timeout: 480 seconds] 10:11 -!- Guest6049 [~nchery@134.134.139.80] has quit [Ping timeout: 480 seconds] 10:11 -!- Guest6049 [~nchery@134.134.139.80] has quit [Ping timeout: 480 seconds] 10:14 -!- jess [~jess@husky.lolnerd.net] has joined #wayland 10:22 #wayland: < pq> swick[m], I have much more comments for the mastering display info request, but we should agree on the terminology first before I can write proper comments. 10:29 #dri-devel: < jani> drm-tip rebuild fails with https://paste.debian.net/1272275/ when merging drm-misc-next 10:31 #dri-devel: < MrCooper> bwidawsk cmeissl[m]: FWIW, if the DRM_IOCTL_MODE_ADDFB2 ioctl fails it's an issue on the compositor side, not the client side, so the device sent to clients in dma-buf feedback shouldn't matter 10:32 #dri-devel: < vsyrjala> client allocates the buffer does it not? 10:33 #dri-devel: < MrCooper> yes, but that can't cause the compositor to use a wrong GEM handle 10:34 -!- apinheiro [~infapi00@fanzine2.igalia.com] has joined #dri-devel 10:37 #dri-devel: < MrCooper> it indicates some kind of mix-up in the compositor process, possibly in Mesa 10:37 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has quit [Read error: Connection reset by peer] 10:37 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has quit [Read error: Connection reset by peer] 10:37 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has joined #etnaviv 10:37 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has joined #dri-devel 10:40 -!- fab [~fab@gandi-2.bellet.info] has quit [Quit: fab] 10:41 -!- kts [~kts@103.73.236.71] has joined #dri-devel 10:41 -!- kts [~kts@103.73.236.71] has joined #intel-gfx 10:41 -!- kts [~kts@103.73.236.71] has joined #intel-3d 10:41 -!- kts [~kts@103.73.236.71] has joined #wayland 10:44 -!- kts [~kts@103.73.236.71] has quit [] 10:44 -!- kts [~kts@103.73.236.71] has quit [] 10:44 -!- kts [~kts@103.73.236.71] has quit [] 10:44 -!- kts [~kts@103.73.236.71] has quit [] 10:45 -!- devilhorns [~devilhorn@2601:80:c980:7400:3a00:25ff:fe4e:1c9a] has joined #wayland 10:45 -!- devilhorns [~devilhorn@2601:80:c980:7400:3a00:25ff:fe4e:1c9a] has joined #dri-devel 10:49 -!- fab [~fab@134.214.236.142] has joined #dri-devel 10:49 -!- ice9 [~ice9@0001f41b.user.oftc.net] has joined #intel-gfx 10:49 -!- ice9 [~ice9@0001f41b.user.oftc.net] has joined #dri-devel 10:50 #dri-devel: < kode54> god dammit 10:50 -!- urja [~Urja@83.146.164.138] has quit [Read error: Connection reset by peer] 10:51 #dri-devel: < kode54> why does CONFIG_DRM_XE have no special requirements, but CONFIG_DRM_XE_DISPLAY requires CONFIG_EXPERT 10:51 -!- urja [~Urja@83.146.164.138] has joined #dri-devel 10:51 #dri-devel: < kode54> I guess it doesn't assume I would be using a pre-baked distribution configuration as my starting template 10:58 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #dri-devel 10:58 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #wayland 10:58 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #radeon 11:00 -!- aravind [~aravind@134.134.137.86] has quit [Ping timeout: 480 seconds] 11:00 -!- aravind [~aravind@134.134.137.86] has quit [Ping timeout: 480 seconds] 11:02 #dri-devel: < mlankhorst> danvet: ping? 11:07 -!- KnM_ [~mdnavare@c-73-157-143-109.hsd1.or.comcast.net] has joined #intel-gfx 11:09 #dri-devel: < digetx> jani: hi, please let me know if you still have that shmem conflict because I don't have it (maybe I'm doing something wrong?) 11:13 #dri-devel: < vsyrjala> happens here too. currently on git 2.39.2, should that make a difference 11:14 -!- KnM [~mdnavare@c-73-157-143-109.hsd1.or.comcast.net] has quit [Ping timeout: 480 seconds] 11:15 #freedesktop: < daniels> bentiss: I didn't realise anyone was using certs 11:15 #dri-devel: < vsyrjala> last drm-tip rebuild was on 25th, but the conflicting stuff was pushed on 27th. so i guess you didn't actually rebuild drm-tip? 11:16 #freedesktop: < bentiss> daniels: k, then I guess we can enable gitlab-sshd. This is what gitlab.com uses, so better get close to them 11:17 #dri-devel: < digetx> have the same git version; when I run `./dim rebuild-tip; cd drm-tip; git diff`, it gives me conflicts for i915 and amdgpu only 11:17 -!- cool110 [~mark@0002e01f.user.oftc.net] has quit [Remote host closed the connection] 11:18 #dri-devel: < jani> digetx: still seeing it 11:18 -!- cool110 [~mark@0002e01f.user.oftc.net] has joined #wayland 11:19 #freedesktop: < alatiera> do those fancy fido keys use ssh certs or do they create normal certs and normal keys to use? 11:20 #dri-devel: < vsyrjala> digetx: so maybe you have a local conflict resolution for this in you rerere, but never pushed since you stopped the rebuild when encountering some i915/amdgpu conflicts? 11:21 #dri-devel: < jani> digetx: given the conflict in the paste, is just choosing the latter part the right resolution? 11:22 #dri-devel: < jani> apparently not, doesn't build 11:24 #freedesktop: < bentiss> alatiera: I think they are creating one ssh key per fido registration, so not cert. 11:25 -!- neobrain [~neobrain@noether.physik.uni-erlangen.de] has quit [Ping timeout: 480 seconds] 11:25 -!- neobrain [~neobrain@noether.physik.uni-erlangen.de] has quit [Ping timeout: 480 seconds] 11:25 -!- neobrain [~neobrain@noether.physik.uni-erlangen.de] has quit [Ping timeout: 480 seconds] 11:27 #wayland: < wlb> wayland-protocols/main: Jonas Ådahl * xdg-output: Remove and tweak contradicting examples https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/94482ceaf9be unstable/xdg-output/xdg-output-unstable-v1.xml 11:27 #wayland: < wlb> wayland-protocols Merge request !195 merged \o/ (xdg-output: Remove and tweak contradicting examples https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/195) 11:27 -!- alatiera4 [~alatiera@193.92.116.70.dsl.dyn.forthnet.gr] has joined #freedesktop 11:27 -!- alatiera4 [~alatiera@193.92.116.70.dsl.dyn.forthnet.gr] has joined #dri-devel 11:27 -!- alatiera4 [~alatiera@193.92.116.70.dsl.dyn.forthnet.gr] has joined #wayland 11:28 -!- alatiera [~alatiera@00026ea6.user.oftc.net] has quit [Ping timeout: 480 seconds] 11:28 -!- alatiera [~alatiera@00026ea6.user.oftc.net] has quit [Ping timeout: 480 seconds] 11:28 -!- alatiera [~alatiera@00026ea6.user.oftc.net] has quit [Ping timeout: 480 seconds] 11:29 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 11:29 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 11:29 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 11:29 #wayland: < DodoGTA> Why does setting the primary screen in xrandr do nothing with XWayland? 11:30 #dri-devel: < digetx> let me try to re-setup the maintainer-tools 11:30 #dri-devel: < jani> but why? 11:30 #wayland: < pq> DodoGTA, xrandr on Xwayland is strictly read-only. It cannot be used to reconfigure the Wayland compositor. 11:32 #wayland: < pq> OTOH, I think Xwayland does support faking video mode changes via RandR, to let apps think they changed it. In reality, video mode does not change. 11:33 #wayland: < emersion> hm i think it's supposed to work DodoGTA 11:33 #dri-devel: < digetx> don't see any local conflict resolutions 11:33 #wayland: < emersion> some sway users have a script to set the X11 primary output via xrandr 11:33 #wayland: < emersion> (this doesn't affect the Wayland compositor in any way) 11:35 #wayland: < pq> DodoGTA, what exactly did you expect to see? 11:35 -!- apinheiro [~infapi00@fanzine2.igalia.com] has quit [Ping timeout: 480 seconds] 11:36 -!- alatiera4 is now known as alatiera 11:36 -!- alatiera4 is now known as alatiera 11:36 -!- alatiera4 is now known as alatiera 11:38 -!- yarda [~irc@0002bae8.user.oftc.net] has quit [Quit: WeeChat 3.8] 11:39 -!- yarda [~irc@epic.nerdrage.nl] has joined #radeon 11:40 #dri-devel: < kode54> I tested the Xe KMD 11:40 #dri-devel: < kode54> it can't find any functioning crtc 11:40 #freedesktop: < daniels> correct 11:41 #freedesktop: < daniels> (well, they can do certs, but they can also just do regular keys - that's what I use with mine) 11:41 #freedesktop: < daniels> bentiss: sounds good, thanks! 11:42 #freedesktop: < daniels> bentiss: just fixed the banner notification 11:45 #freedesktop: < emersion> can we remove the +M on this channel? 11:45 -!- apinheiro [~infapi00@fanzine2.igalia.com] has joined #dri-devel 11:45 #freedesktop: < emersion> to allow new users to request support more easily? 11:48 #freedesktop: < daniels> sauce: akismet is enabled fwiw 11:48 #freedesktop: < daniels> emersion: sure we can try it, we used to get absolutely smashed by spam however 11:48 -!- mode/#freedesktop [+o daniels] by ChanServ 11:49 -!- mode/#freedesktop [+nt] by ChanServ 11:49 #freedesktop: < emersion> we've had an open channel in libera forever, had spam once only 11:49 -!- mode/#freedesktop [-o daniels] by daniels 11:49 -!- mode/#freedesktop [+nt] by ChanServ 11:49 #freedesktop: < emersion> thanks! 11:49 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has quit [Quit: Leaving] 11:49 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has quit [Quit: Leaving] 11:49 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has quit [Quit: Leaving] 11:49 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has quit [Quit: Leaving] 11:49 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has quit [Quit: Leaving] 11:49 #freedesktop: < emersion> we can always switch it back if it's an issue 11:50 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has joined #dri-devel 11:50 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has joined #intel-gfx 11:50 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has joined #nouveau 11:50 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has joined #radeon 11:50 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has joined #wayland 11:51 #freedesktop: < pq> um, you didn't actually remove M, did you? 11:51 #dri-devel: < daniels> cmeissl[m]: yeah, so the root of your issue is that FD_TO_HANDLE is failing. that's telling you that you can't import the dmabuf into your scanout device. anything beyond that is not going to give you good results. it sounds like this is being caused because platform_wayland isn't invoking the kmsro infrastructure to make it aware of the scanout device as well. probably a bunch more typing required there. this does work for most 11:51 #dri-devel: < daniels> devices, but i.MX6 is just the worst possible case. 11:51 #freedesktop: < pq> irssi thinking +M is still here 11:53 #dri-devel: < jani> digetx: no matter what, the last drm-tip rebuild as well as last drm-rerere update was 2023y-02m-25d-19h-52m-27s UTC 11:54 #dri-devel: < daniels> hakzsam: I know people were busy last week, so I've kicked again 11:54 #dri-devel: < daniels> hakzsam: tintou is looking into itnow 11:54 #freedesktop: < daniels> pq: 'Channel mode set to +nt by ChanServ' 11:55 -!- mode/#freedesktop [+o daniels] by ChanServ 11:55 -!- mode/#freedesktop [+nt] by daniels 11:55 -!- mode/#freedesktop [-o daniels] by daniels 11:55 #freedesktop: < pq> I see that, but [5:#freedesktop(+Mnt)] 11:55 #dri-devel: < jani> tzimmermann: mripard: mlankhorst: please look into getting the conflict between drm-misc branches resolved 11:55 #freedesktop: < daniels> yeah, /mode #freedesktop shows the same here 11:55 #freedesktop: * daniels shrugs 11:55 #freedesktop: < pq> don't you need to -M instead of +nt? 11:57 #dri-devel: * jani .oO( if we were doing gitlab merge requests, it could warn in advance that merging something will cause a drm-tip rebuild conflict instead of after the fact ) 11:58 #dri-devel: < tzimmermann> jani, looking... 11:59 -!- fab_ [~fab@134.214.236.142] has joined #dri-devel 11:59 -!- fab_ is now known as Guest6057 12:02 -!- anarsoul|2 [~anarsoul@000140ae.user.oftc.net] has quit [Read error: Connection reset by peer] 12:02 -!- anarsoul|2 [~anarsoul@000140ae.user.oftc.net] has quit [Read error: Connection reset by peer] 12:02 -!- anarsoul|2 [~anarsoul@000140ae.user.oftc.net] has quit [Read error: Connection reset by peer] 12:02 -!- anarsoul|2 [~anarsoul@000140ae.user.oftc.net] has quit [Read error: Connection reset by peer] 12:02 -!- anarsoul [~anarsoul@S010636a45eaa632e.vf.shawcable.net] has joined #wayland 12:02 -!- anarsoul [~anarsoul@S010636a45eaa632e.vf.shawcable.net] has joined #dri-devel 12:02 -!- anarsoul [~anarsoul@S010636a45eaa632e.vf.shawcable.net] has joined #lima 12:02 -!- anarsoul [~anarsoul@S010636a45eaa632e.vf.shawcable.net] has joined #nouveau 12:03 #dri-devel: < tzimmermann> jani, fixed 12:04 #dri-devel: < tzimmermann> the problem is that people land their patches and then walk away without looking for errors in the merge process 12:05 -!- fab [~fab@134.214.236.142] has quit [Ping timeout: 480 seconds] 12:06 #dri-devel: < hays> was going to ask again, sorry for the repeat, but i am curious if anyone can recommend tools or methods to get screen resolution and sizing reliably before X is running? 12:07 -!- Moprius [~Thunderbi@177.51.37.15] has joined #radeon 12:07 -!- Moprius [~Thunderbi@177.51.37.15] has joined #wayland 12:07 -!- Moprius [~Thunderbi@0002e253.user.oftc.net] has quit [] 12:07 -!- Moprius [~Thunderbi@0002e253.user.oftc.net] has quit [] 12:07 #dri-devel: < hays> i found fbset which is a little helpful, but I dont have an /etc/fb.modes 12:09 -!- Misanthropos [~Misanthro@216.24.213.37] has joined #nouveau 12:09 #dri-devel: < hays> am trying to (1) find out which device is connected (2) what the maximum or recommended resolution is, set that resolution 12:10 #dri-devel: < cmeissl[m]> MrCooper daniels thanks! yes, I did try calling primeFdToHandle directly and it indeed already fails, so the failure of drmModeAddFB2 is to be expected. So I was on the right track with kmsro at least. From the code I am not sure how kmsro is expected to work in combination with dmabuf feedback. When I send the render node from etnaviv (renderD128) as the main device it will happily use dmabuf feedback, and also set the required 12:10 #dri-devel: < cmeissl[m]> `__DRI_IMAGE_USE_SCANOUT` flag if a scan-out tranche is sent, but it won't initialize kmsro. Sending card1 (imx-drm) as the main device will initialize kmsro, but disable dmabuf feedback and fallback to wl_drm. I guess that is caused by `loader_get_render_node` returning NULL in `default_dmabuf_feedback_main_device`. 12:10 -!- DodoGTA [~DodoGTA@5.20.104.245] has quit [Quit: DodoGTA] 12:10 -!- DodoGTA [~DodoGTA@5.20.104.245] has quit [Quit: DodoGTA] 12:10 -!- DodoGTA [~DodoGTA@5.20.104.245] has quit [Quit: DodoGTA] 12:11 -!- DodoGTA [~DodoGTA@5.20.104.245] has joined #wayland 12:11 -!- DodoGTA [~DodoGTA@5.20.104.245] has joined #nouveau 12:11 -!- DodoGTA [~DodoGTA@5.20.104.245] has joined #freedesktop 12:11 -!- Company [~Company@ip1f1264d8.dynamic.kabel-deutschland.de] has joined #dri-devel 12:11 -!- Company [~Company@ip1f1264d8.dynamic.kabel-deutschland.de] has joined #wayland 12:12 -!- DodoGTA [~DodoGTA@5.20.104.245] has quit [] 12:12 -!- DodoGTA [~DodoGTA@5.20.104.245] has quit [] 12:12 -!- DodoGTA [~DodoGTA@5.20.104.245] has quit [] 12:12 -!- DodoGTA [~DodoGTA@5.20.104.245] has joined #wayland 12:12 -!- DodoGTA [~DodoGTA@5.20.104.245] has joined #nouveau 12:12 -!- DodoGTA [~DodoGTA@5.20.104.245] has joined #freedesktop 12:12 #dri-devel: < digetx> tzimmermann: hoped that refreshing of maintainers-tool will help (it's fetching src git a bit too slow), not sure why I don't see that conflict 12:13 #dri-devel: < cmeissl[m]> And am I right, that as long as the client does not initialize kmsro it is expected to fail? 12:13 #dri-devel: < tzimmermann> no idea 12:13 #dri-devel: < digetx> now I'm thinking that I may've had a local remote branch that helped to resolve the conflict 12:14 -!- floof58 is now known as Guest6060 12:14 -!- floof58 is now known as Guest6060 12:14 -!- floof58 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has joined #radeon 12:14 -!- floof58 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has joined #wayland 12:14 #dri-devel: < tzimmermann> digetx, how old is your git. IIRC older git versions don't deal well with new tools. but i don't remember the exact problems they had 12:14 #dri-devel: < vsyrjala> i don't rebuild-tip should use local branches (apart from rerere) 12:15 #dri-devel: < vsyrjala> i don't think... 12:15 #dri-devel: < tzimmermann> yeah, the local branch does not affect the merging 12:16 #dri-devel: < digetx> "git version 2.39.2" 12:16 #dri-devel: < tzimmermann> same as here 12:16 #dri-devel: < digetx> (gentoo) 12:16 #dri-devel: < tzimmermann> then this isn't the problem either 12:16 -!- Guest6060 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has quit [Ping timeout: 480 seconds] 12:16 -!- Guest6060 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has quit [Ping timeout: 480 seconds] 12:17 #dri-devel: < tzimmermann> anyway, it's now fixed https://cgit.freedesktop.org/drm/drm-tip/commit/ 12:17 -!- mmu_man [~revol@82-65-227-82.subs.proxad.net] has joined #nouveau 12:19 #dri-devel: < vsyrjala> an now it doesn't build 12:20 -!- Guest6057 [~fab@134.214.236.142] has quit [] 12:20 #dri-devel: < vsyrjala> ../drivers/gpu/drm/drm_gem_shmem_helper.c:651:15: error: implicit declaration of function ‘drm_gem_shmem_get_pages_locked’; did you mean ‘drm_gem_shmem_get_pages_sgt_locked’? [-Werror=implicit-function-declaration] 12:21 -!- fab [~fab@134.214.236.142] has joined #dri-devel 12:21 #dri-devel: < jani> digetx: given the conflict in the paste, is just choosing the latter part the right resolution? 12:21 #dri-devel: < jani> apparently not, doesn't build 12:21 #dri-devel: < jani> the same error : | 12:21 -!- bvivekan [~bvivekan@122.166.101.63] has joined #intel-gfx 12:22 #dri-devel: < jani> pro-tip, when resolving something in drm-tip, just do make olddefconfig; make path/to/conflicting/file.o 12:22 #dri-devel: < jani> before actually committing 12:23 #dri-devel: < vsyrjala> i just test build the whole thing 12:27 #dri-devel: < digetx> jani: yes, the pages_lock is replaced with the resv lock 12:29 #dri-devel: < digetx> the drm_gem_shmem_get_pages_locked isn't correct, though 12:30 #dri-devel: < digetx> jani: not sure where you've got the 12:30 #dri-devel: < digetx> - ret = drm_gem_shmem_get_pages(shmem); 12:30 #dri-devel: < digetx> + ret = drm_gem_shmem_get_pages_locked(shmem); 12:30 #dri-devel: < digetx> it should be the other way around 12:33 #dri-devel: < jani> it's a conflict between drm-misc-next-fixes and drm-misc-next 12:33 #dri-devel: < digetx> the drm_gem_shmem_get_pages() is always locked after conversion to use resv locks, I dropped the _locked() part 12:33 #dri-devel: < jani> ddddedaa0db9 ("drm/shmem-helper: Fix locking for drm_gem_shmem_get_pages_sgt()") 12:35 #dri-devel: < emersion> mripard: hm it seems like vc4 calls drm_mode_create_tv_properties() but ignores tv brightness? 12:36 #dri-devel: < mripard> afaik, it only uses the TV margins yeah 12:36 #dri-devel: < emersion> then it's incorrect to call drm_mode_create_tv_properties()? 12:36 #dri-devel: < emersion> vc4/vc4_vec.c:756: ret = drm_mode_create_tv_properties(drm, 12:38 #dri-devel: < kode54> xe kmd fails here with these traces: http://ix.io/4pms 12:38 #dri-devel: < digetx> jani: but both next and next fixes have ddddedaa0db9 12:39 #dri-devel: < danvet> mlankhorst, back from vacations 12:41 -!- fab [~fab@134.214.236.142] has quit [Quit: fab] 12:41 -!- fab [~fab@134.214.236.142] has joined #dri-devel 12:41 #dri-devel: < vsyrjala> emersion: creating the props should be fine. but attaching props you don't support would be wrong 12:41 #dri-devel: < emersion> ah 12:42 -!- gtristan [~tristan@223.38.35.227] has quit [Remote host closed the connection] 12:42 -!- gtristan [~tristan@223.38.35.227] has joined #freedesktop 12:43 -!- YuGiOhJCJ [~YuGiOhJCJ@00021b1f.user.oftc.net] has joined #dri-devel 12:43 #dri-devel: < emersion> hm, weird, gud seems to support tv_brightness but doesn't expose it 12:43 #dri-devel: < emersion> doesn't attach it* 12:44 #dri-devel: < emersion> the only driver to attach it is ch7006 12:46 -!- gtristan [~tristan@223.38.35.227] has quit [Remote host closed the connection] 12:46 -!- gtristan [~tristan@223.38.35.227] has joined #freedesktop 12:47 -!- gtristan [~tristan@223.38.35.227] has quit [Remote host closed the connection] 12:48 -!- gtristan [~tristan@223.38.35.227] has joined #freedesktop 12:50 -!- mowcat [~mowcat@2a00:23c5:d190:1901:f22f:74ff:fe77:1e1c] has joined #radeon 12:53 -!- Paul33 [~Paul33@mob-5-91-104-76.net.vodafone.it] has joined #wayland 12:53 -!- Paul33 [~Paul33@mob-5-91-104-76.net.vodafone.it] has joined #nouveau 12:54 -!- gtristan [~tristan@223.38.35.227] has quit [Remote host closed the connection] 12:55 -!- gtristan [~tristan@223.38.35.227] has joined #freedesktop 12:56 #freedesktop: < karolherbst> daniels: do any spam accounts use social logins? Just saw the spam notice today and I was wondering if that's something we could rely on 12:56 -!- aravind [~aravind@134.134.137.86] has joined #intel-gfx 12:56 -!- aravind [~aravind@134.134.137.86] has joined #dri-devel 12:56 -!- gtristan [~tristan@223.38.35.227] has quit [Remote host closed the connection] 12:56 -!- jkrzyszt [~jkrzyszt@134.191.221.86] has quit [Remote host closed the connection] 12:56 -!- jkrzyszt [~jkrzyszt@134.191.221.86] has quit [Remote host closed the connection] 12:57 #freedesktop: < karolherbst> like anybody signing up through github/whatever gets full access, everybody who still wants to do email + password has to do the annoying part 12:57 -!- gtristan [~tristan@223.38.35.227] has joined #freedesktop 12:57 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has quit [Ping timeout: 480 seconds] 12:57 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has quit [Ping timeout: 480 seconds] 12:57 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has quit [Ping timeout: 480 seconds] 12:58 -!- gtristan [~tristan@223.38.35.227] has quit [Remote host closed the connection] 12:59 -!- gtristan [~tristan@223.38.35.227] has joined #freedesktop 12:59 #freedesktop: < emersion> and next we give out free R-b tags for people logging in via Twitter 12:59 #freedesktop: < karolherbst> what does that have to do with anything? 13:00 #freedesktop: < emersion> freedesktop promoting free platforms, nice 13:00 -!- vkareh [~vkareh@00026f70.user.oftc.net] has joined #freedesktop 13:00 #freedesktop: < karolherbst> ehhh.. I didn't come here to bikeshed, sorry 13:00 #freedesktop: < pq> emersion, stop the sarcarm and just say what you think. 13:00 #freedesktop: < pq> *sarcasm 13:00 #dri-devel: < digetx> jani: now I see that it's actually drm/drm-next that fails to merge for drm-tip and not misc-next, do you have conflict resolution for drm-next? or how it all works, what am I missing :) 13:01 -!- nchery is now known as Guest6063 13:01 -!- nchery is now known as Guest6063 13:01 -!- nchery is now known as Guest6063 13:01 -!- nchery [~nchery@134.134.139.80] has joined #intel-gfx 13:01 -!- nchery [~nchery@134.134.139.80] has joined #intel-3d 13:01 -!- nchery [~nchery@134.134.139.80] has joined #dri-devel 13:01 #freedesktop: < pq> Sarcasm only makes communication more difficult and agitating. It's not even funny. 13:02 #freedesktop: < emersion> okay, sorry 13:02 #freedesktop: < karolherbst> anyway, social logins are the best options for users already, not because we want to, just because fully open solutions suck 13:02 -!- Guest6063 [~nchery@134.134.139.80] has quit [Ping timeout: 480 seconds] 13:02 -!- Guest6063 [~nchery@134.134.139.80] has quit [Ping timeout: 480 seconds] 13:02 -!- Guest6063 [~nchery@134.134.139.80] has quit [Ping timeout: 480 seconds] 13:03 #freedesktop: < pq> thanks - I have a hard time detecting sarcasm sometimes 13:03 #freedesktop: < karolherbst> honestly.. we should just disable password logins 🙃 13:03 #freedesktop: < emersion> what 13:04 #freedesktop: < karolherbst> less strain on our admins 13:04 #dri-devel: < jani> digetx: drm-tip rebuild (regeneration) works fine now; unfortunately the actual build fails due to the wrong conflict resolution 13:04 #freedesktop: < emersion> i'll just go away and assume you're trolling 13:04 #dri-devel: < jani> digetx: are you new to dim? 13:04 #freedesktop: < karolherbst> I wouldn't be surprised if all spam comes in via email + password logins 13:04 #dri-devel: < jani> no value judgement there; just checking the facts ;) 13:04 #freedesktop: < karolherbst> no, I'm dead serious 13:05 #freedesktop: < karolherbst> if that means less work for our admins, and spam basically gone... 13:05 #dri-devel: < DavidHeidelberg[m]> mupuf: 👀curl for the container, pretty please :P 13:05 #freedesktop: < emersion> if you're that serious, we should migrate to github and discord, then we don't need admins anymore 13:05 #freedesktop: < karolherbst> if not, we have to seriously think about paying admins from foundation money 13:06 #freedesktop: < karolherbst> yes, I am. our admins are heavily overworked and nobody seems to care and just "request everything even if it means more work". I'm at least try to be sensible here 13:06 #dri-devel: < digetx> jani: kind of new to dim, yes; I can apply patches with dim, but skipped the drm-tip part because previously all the conflict were complicated and irrelevant to my changes 13:06 #freedesktop: < karolherbst> if password logins are a constant pain, we should consider ditching them 13:07 #freedesktop: < karolherbst> or well.. _pay_ admins 13:08 -!- kts [~kts@103.73.236.64] has joined #dri-devel 13:08 -!- kts [~kts@103.73.236.64] has joined #intel-gfx 13:08 -!- kts [~kts@103.73.236.64] has joined #intel-3d 13:08 -!- kts [~kts@103.73.236.64] has joined #wayland 13:08 -!- gtristan [~tristan@223.38.35.227] has quit [Read error: Connection reset by peer] 13:08 -!- gtristan_ [~tristan@223.38.35.227] has joined #freedesktop 13:08 #dri-devel: < jani> digetx: well, basically applying patches with dim must include addressing any resulting conflicts in drm-tip rebuild. whoever applies patches and it causes conflicts in drm-tip rebuild is on the hook for either resolving them or pulling in folks to help 13:09 #dri-devel: < jani> digetx: if you leave them unresolved, the conflicts pile up as people apply more, and it gets harder 13:10 #freedesktop: < karolherbst> anyway.. not needing admins > demanding free work from admins 13:10 -!- jmdaemon [~jmdaemon@0002d6bd.user.oftc.net] has quit [Ping timeout: 480 seconds] 13:11 #dri-devel: < vsyrjala> hmm. could we make dim do a test rebuild-tip _before_ pushing anything new? would prevent conflicts from piling up and thus making it hard for any single person to resolve the mess 13:11 #dri-devel: < jani> if you develop on top of drm-tip, and send patches from there, and they fail to apply to an individual branch, it's a good indicator a conflict will occur 13:12 #dri-devel: < jani> vsyrjala: it's racy, as is the current approach 13:14 #dri-devel: < jani> adding the local build of drm-tip makes the race window longer 13:14 -!- itoral [~itoral@100.49.60.213.dynamic.reverse-mundo-r.com] has quit [Remote host closed the connection] 13:15 #dri-devel: < digetx> seems I figured out what was going on wrong all that time.. I had rerere disabled in my .git global config 13:16 #dri-devel: < vsyrjala> jani: i suppose. though i don't think our usual problems have been due to the racyness. more because people forget to check the results of the rebuild 13:17 #dri-devel: < vsyrjala> another idea could be to have ci/something complain if drm-tip is lagging behind 13:18 #dri-devel: < zmike> mareko: did you have issues with the tc query MR or just questions 13:18 #dri-devel: < digetx> jani: finally, I've the drm_gem_shmem_get_pages_locked -Werr after fixing rerere \o/ 13:18 #dri-devel: < jani> digetx: right, maybe send a patch to dim to check that config ;) 13:18 -!- nchery is now known as Guest6065 13:18 -!- nchery is now known as Guest6065 13:18 -!- nchery is now known as Guest6065 13:18 -!- nchery [~nchery@134.134.139.80] has joined #intel-gfx 13:18 -!- nchery [~nchery@134.134.139.80] has joined #intel-3d 13:18 -!- nchery [~nchery@134.134.139.80] has joined #dri-devel 13:18 -!- neobrain [~neobrain@noether.physik.uni-erlangen.de] has joined #dri-devel 13:18 -!- neobrain [~neobrain@noether.physik.uni-erlangen.de] has joined #radeon 13:18 -!- neobrain [~neobrain@noether.physik.uni-erlangen.de] has joined #wayland 13:19 #dri-devel: < jani> vsyrjala: I've had some ideas wrt that, it could flag the conflicts and identify which patch/push caused it and everything, but it's the kind of yak shaving that doesn't just happen :( 13:22 -!- gtristan_ [~tristan@223.38.35.227] has quit [Remote host closed the connection] 13:22 -!- gtristan_ [~tristan@223.38.35.227] has joined #freedesktop 13:22 -!- JohnDoe_71Rus [~CLDX@80.78.195.138] has quit [] 13:23 -!- gtristan_ [~tristan@223.38.35.227] has quit [Remote host closed the connection] 13:24 -!- gtristan_ [~tristan@223.38.35.227] has joined #freedesktop 13:25 -!- Guest6065 [~nchery@134.134.139.80] has quit [Ping timeout: 480 seconds] 13:25 -!- Guest6065 [~nchery@134.134.139.80] has quit [Ping timeout: 480 seconds] 13:25 -!- Guest6065 [~nchery@134.134.139.80] has quit [Ping timeout: 480 seconds] 13:29 -!- kts [~kts@103.73.236.64] has quit [Quit: Konversation terminated!] 13:29 -!- kts [~kts@103.73.236.64] has quit [Quit: Konversation terminated!] 13:29 -!- kts [~kts@103.73.236.64] has quit [Quit: Konversation terminated!] 13:29 -!- kts [~kts@103.73.236.64] has quit [Quit: Konversation terminated!] 13:33 -!- molinari [~molinari@176-151-233-216.abo.bbox.fr] has quit [Ping timeout: 480 seconds] 13:33 -!- molinari [~molinari@67.167.185.81.rev.sfr.net] has joined #wayland 13:34 -!- gtristan_ [~tristan@223.38.35.227] has quit [Ping timeout: 480 seconds] 13:35 -!- nerdopolis [~quassel@pool-108-34-238-21.prvdri.fios.verizon.net] has quit [Remote host closed the connection] 13:37 -!- nerdopolis [~quassel@pool-108-34-238-21.prvdri.fios.verizon.net] has joined #wayland 13:38 #freedreno: < krh> just switch to rust already ;-P 13:39 -!- gtristan [~tristan@223.38.35.227] has joined #freedesktop 13:44 #intel-3d: < zmike> would it be possible to add INTEL_DEBUG=zerovram like radv has? 13:45 #freedesktop: < bentiss> karolherbst: the problem is that most spams are using google auth AFAICT, because they could create an account and immediately do their shit 13:46 #freedesktop: < bentiss> it was relativcely hard for users+pass users to create their accounts, but it didn't stop the last wave of spam 13:47 #dri-devel: < digetx> jani: so that drm_gem_shmem_get/put_pages_locked build error in drm-tip now is due to a wrong merge conflict resolution? should me/we do anything about it? 13:48 #freedesktop: < karolherbst> mhh 13:48 #dri-devel: < vsyrjala> you need to revert that from rerere, and then do it right 13:48 #freedesktop: < karolherbst> I guess a lot of users are on google auth? 13:48 #freedesktop: < bentiss> sigh... last spam user: https://gitlab.freedesktop.org/onfiretvc -> no gauth ;( 13:49 -!- gtristan [~tristan@223.38.35.227] has quit [Remote host closed the connection] 13:49 #freedesktop: < karolherbst> so where is the most spam coming from? google + password? 13:49 #freedesktop: < bentiss> same for https://gitlab.freedesktop.org/admin/users/espntv -> not a google one 13:50 #freedesktop: < karolherbst> how are other gitlab instances dealing with this problem? 13:50 -!- gtristan [~tristan@223.38.35.227] has joined #freedesktop 13:50 #freedesktop: < bentiss> karolherbst: in the backlog, IIRC alatiera said that gnome temporarily blocked new users entirely 13:50 #freedesktop: < karolherbst> mhh 13:51 #freedesktop: < karolherbst> maybe just block google then 🙃 13:51 #freedesktop: < bentiss> and FWIW, at least with preventing users to create new projects, now the spam is way more visible to fdo maintainers, not just admins 13:51 #freedesktop: < karolherbst> seems a lot of people are tired of their shit 13:51 #freedesktop: < bentiss> karolherbst: again, the last 2 ones are not using google 13:52 #freedesktop: < karolherbst> right... 13:52 -!- Zopolis4 [uid504804@id-504804.ilkley.irccloud.com] has quit [] 13:52 #freedesktop: < karolherbst> but in the end it's about what's the biggest source of spam 13:52 -!- gtristan [~tristan@223.38.35.227] has quit [Remote host closed the connection] 13:52 #freedesktop: < bentiss> well, too late to do stats now. When the users are nuked, we don't have a trace of them (unless digging in the db backups, which is a pain TBH) 13:53 -!- xmn [~xmn@cpe-72-225-198-203.nyc.res.rr.com] has joined #radeon 13:53 #freedesktop: < karolherbst> heh, fair 13:53 -!- gtristan [~tristan@223.38.35.227] has joined #freedesktop 13:53 -!- Paul33 [~Paul33@mob-5-91-104-76.net.vodafone.it] has quit [Ping timeout: 480 seconds] 13:53 -!- Paul33 [~Paul33@mob-5-91-104-76.net.vodafone.it] has quit [Ping timeout: 480 seconds] 13:53 #freedesktop: < karolherbst> I suspect you already have some IP checking stuff set up? 13:54 -!- gtristan [~tristan@223.38.35.227] has quit [Remote host closed the connection] 13:54 -!- gtristan [~tristan@223.38.35.227] has joined #freedesktop 13:54 #freedesktop: < bentiss> so far, I think the best course would be to share the new users enboarding by all maintainers: a new user need to create a repo, it requests the project and the instance, then project maintainers answer a simple ack, and then a bot/sth mark the user as internal 13:55 #freedesktop: < karolherbst> new project also means fork, no? 13:55 #freedesktop: < bentiss> there are already limitations through akismet and reCaptcha, even if it means more people grumbling here 13:55 #freedesktop: < bentiss> karolherbst: yeah 13:55 #freedesktop: < karolherbst> :'( 13:56 #freedesktop: < karolherbst> kind of don't like where this is going, because at some point nobody will bother anymore 13:56 -!- gtristan [~tristan@223.38.35.227] has quit [Remote host closed the connection] 13:56 #freedesktop: < bentiss> actually, one thing I haven't got to was work on the regex to automatically validate intel, collabora, red hat emails... 13:56 #freedesktop: < karolherbst> yes.. but... that still doesn't address random new contributors coming in 13:56 -!- gtristan [~tristan@223.38.35.227] has joined #freedesktop 13:57 #freedesktop: < karolherbst> if you do it for your job, then you deal with the pain 13:57 #freedesktop: < karolherbst> so it wouldn't really change anything 13:57 #freedesktop: < bentiss> agree, and again before they were shouting in the void for help, now they can at least ask the projects to help them 13:57 -!- fxkamd [~Thunderbi@lnsm2-torontoxn-142-116-149-103.dsl.bell.ca] has joined #radeon 13:57 -!- fxkamd [~Thunderbi@lnsm2-torontoxn-142-116-149-103.dsl.bell.ca] has joined #dri-devel 13:57 #freedesktop: < karolherbst> my point is, if I'd want to contribute patches and I'd have to request to be allowed to fork, I'd just go away 13:58 #freedesktop: < karolherbst> and I suspect a lot of people will think the same 13:58 #freedesktop: < alatiera> bentiss I think initially it was only gmail/outlook/otherfreemail that were blocked from registering but due to ongoing spam I think both google signin and new registrations were blocked for now 13:59 #freedesktop: < karolherbst> maybe we should just put those restrictions for google + ...@gmail.com 🙃 13:59 #freedesktop: < karolherbst> maybe we should also start collecting stats from where spam is comming from 13:59 #freedesktop: < karolherbst> but what I hear is, that it's usually google where it's all coming from, either via email or other means 13:59 #freedesktop: < karolherbst> and that google won't solve it, because nobody dares to block them 13:59 #freedesktop: < bentiss> karolherbst: as you already said, we don't have paid admins... so getting those stas is *low* on my todo list 13:59 #freedesktop: < karolherbst> yeah 13:59 #freedesktop: < karolherbst> we should address it in the foundation 14:00 #freedesktop: < karolherbst> can't continue like that 14:00 #freedesktop: < karolherbst> and if some board member disagree, foundation members should reconsider _Strongly_ if those individuals actually act in the best interest for fdo 14:00 #freedesktop: < karolherbst> I've heard stories where proposals like that were shot down 14:01 #freedesktop: < bentiss> karolherbst: the new setting is live since last Friday. Do you have a lot of people complaining that they can not fork? Because all I hear was one user that wanted to have the setting back on 14:01 #freedesktop: < karolherbst> my point is: most users won't complain and just move on 14:01 #freedesktop: < bentiss> if we deal with 10 users a week, we can definitely have a manual process 14:01 #freedesktop: < karolherbst> do you know how many users just move on? 14:01 #freedesktop: < bentiss> neither do you I guess :) 14:02 #freedesktop: < karolherbst> yeah, that's why we can't make any conclusions here 14:02 #freedesktop: < karolherbst> sure, might be 1 who is willing to complain 14:02 #freedesktop: < karolherbst> and we know that 14:02 #freedesktop: < karolherbst> but maybe 50 or 100 just move on (unlikely), but we just don't know 14:02 -!- agd5f_ [~agd5f@76.1.162.23] has joined #freedesktop 14:02 -!- agd5f_ [~agd5f@76.1.162.23] has joined #wayland 14:02 -!- agd5f_ [~agd5f@76.1.162.23] has joined #intel-gfx 14:02 -!- agd5f_ [~agd5f@76.1.162.23] has joined #intel-3d 14:02 -!- agd5f_ [~agd5f@76.1.162.23] has joined #nouveau 14:02 -!- agd5f_ [~agd5f@76.1.162.23] has joined #radeon 14:02 -!- agd5f_ [~agd5f@76.1.162.23] has joined #dri-devel 14:03 #wayland: < DodoGTA> pq: So how can I force an Xorg app to run on a specific screen without changing the primary screen in KDE? 14:03 #wayland: < DodoGTA> Specifically a fullscreen one 14:05 #wayland: < pq> can't you just... move it there? 14:06 #wayland: < pq> or does it force itself to a wrong output? 14:06 #freedesktop: < bentiss> TBH I think that fear of losing "contributors" who did not even bother to try to talk to the project members is rather worrying. Open Source is social by essence, so even when you want to submit a patch, you have to talk to someone, so if you can not fork but want to fix your bug, you can find a way by opening an issue on the project and saying "I've got this nice patch, how do I 14:06 #freedesktop: < bentiss> submit it?" 14:07 #dri-devel: < nroberts> does anybody know if the Intel CI has a rust compiler? would it be a pain if the rust port of vkrunner was merged into the master branch? it would at least have to be updated to build using ninja instead of cmake 14:09 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:09 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:09 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:09 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:09 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:09 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:09 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:09 #wayland: < pq> I have no idea how KDE works there, user interfaces are up to each DE. The Wayland compositor always has the last say in the matter, so you need to somehow tell it what you want. 14:09 #freedesktop: < bentiss> and also, I am past the point where I can take the arguments of "we should lower the entry bar so we get new contributors" because this is what we had for years, and the amount of valid users compared to spam account is really worrying, knowing that up to now, only a handful of admins were seeing them, and nobody cared really 14:10 #freedesktop: < karolherbst> yeah.. spam is a problem and I wished I had a better solution here 14:10 #wayland: < DodoGTA> pq: KDE can weirdly change the XRandR primary screen, but XRandR can't 14:11 #freedesktop: < MrCooper> I agree, can't see drive-by contributions making up for the cost 14:11 #freedesktop: < karolherbst> but without knowing where it's mostly coming from it's also hard to think about what to do. 14:11 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #freedesktop 14:11 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #wayland 14:11 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #intel-gfx 14:11 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #intel-3d 14:11 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #nouveau 14:11 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #radeon 14:11 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #dri-devel 14:11 #wayland: < DodoGTA> The particular app does start on that primary screen by default with no way to change it 14:12 #freedesktop: < bentiss> over the week end I was thinking at an other way of entry for new contributors, but if I also think at the kernel move to gitlab, one thing that was a complain from other kernel developers was that they had to also create an account on gitlab.fd.o to be able to take part on the discussions 14:12 #freedesktop: < karolherbst> yeah.. I'm not debating this on a "making up for the cost" ground. 1. nobody has the data and 2. nobody knows what drive-by contributor could become a strong future member. As I said, those restrictions would already have driven me away. 14:12 #freedesktop: < karolherbst> not saying that we should keep the load for our admins 14:12 #intel-3d: < gfxstrand> Probably. i915 typicaly zeroes BOs now, unless you're on discrete. 14:12 #freedesktop: < karolherbst> and reducing the load is important 14:12 #freedesktop: < karolherbst> it's just a twisted way to think about this 14:13 #freedesktop: < karolherbst> yeah 14:13 #freedesktop: < karolherbst> social logins are great here tho 14:13 #freedesktop: < bentiss> so I wonder if we should not have a public inbox like for our projects, a bidirectional one, that drive by users could use the same old fashion as sending an email to send their patch 14:13 #freedesktop: < karolherbst> but then you still need to fork and... 14:13 #dri-devel: < digetx> jani: vsyrjala: should be fixed now 14:13 #intel-3d: < zmike> turns out I don't need it since not writing the memory at all didn't produce any changes 14:13 #freedesktop: < karolherbst> yeah.. that might work 14:14 #freedesktop: < bentiss> but I know *a lot* of developers are not happy with email patches :) 14:14 #freedesktop: < karolherbst> might be something gitlab could also implement? dunno 14:14 #freedesktop: < karolherbst> well 14:14 #freedesktop: < karolherbst> could be something which turns patches into MRs 14:14 #freedesktop: < karolherbst> but uhh 14:14 #freedesktop: < karolherbst> the back channel would be annoying 14:14 #freedesktop: < bentiss> we already had something like that internally, at Red Hat, but it was a pain to maintain 14:14 #freedesktop: < karolherbst> yeah... 14:14 #freedesktop: < karolherbst> well 14:15 #freedesktop: < karolherbst> maybe the kernel should have its own gitlab instance instead... 14:15 #freedesktop: < bentiss> that will never happen 14:15 #freedesktop: < karolherbst> then we'll have to deal with having 100 gitlab instances for kernel devel 14:15 #freedesktop: < bentiss> look at the kernel BZ, it was never meant to be official, and people still complain about it 14:15 #dri-devel: < nroberts> I mean meson 14:15 #wayland: < zzag> DodoGTA: for kwin specifically, you could use a window rule; if you have control over source code of the app, you could just make sure that the app sets the corresponding hints so kwin places the window on some specific output 14:15 #freedesktop: < karolherbst> I mean.. it's under kernel.org, no? 14:16 #freedesktop: < karolherbst> (it's even linked there) 14:16 #freedesktop: < bentiss> yes, and the fact that it is under kernel.org makes it seems like it's the way to report bugs, when it's not 14:16 #intel-3d: < gfxstrand> heh 14:16 #dri-devel: < vsyrjala> digetx: builds now. thanks 14:16 #freedesktop: < karolherbst> well.. users see the "bugzilla" link on kernel.org and go there 14:16 #freedesktop: < bentiss> it was historically created to please a few maintainers, and was never said to be THE source for having bugs 14:17 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 14:17 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 14:17 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 14:17 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 14:17 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 14:17 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 14:17 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 14:17 #freedesktop: < karolherbst> anyway 14:17 #freedesktop: < karolherbst> if there won't be a central gitlab instance for kernel devel, and people insisting on mailing lists, then the fragmentation will happen by choice 14:17 #freedesktop: < bentiss> and now, all maintainers have to deal with the pain. There are a few threads on the LKML about retiring it, or having someone to redirect new bugs to their respective maintainers 14:17 #dri-devel: < digetx> awesome, thank you all! the disabled rerere in my git confit was very obscure and confusing to me 14:18 #dri-devel: < vsyrjala> digetx: btw i see you ended up with some extra reverts in rerere. 'dim -d rebuild-tip' is useful when messing about with conflicts. i always use that until i have it fully nailed down, and then drop the -d for the final rebuild 14:18 #freedesktop: < bentiss> Konstantin has a strong opinion against any forge, and in a way, he has a point when he says that email is the only way to have a distributed system that works for everybody 14:18 #freedesktop: < karolherbst> but anyway, that's not doing anything for our spam problem. The biggest question in the end I think is, is the problem _that_ huge a full time admin couldn't deal with and it's just because all the admin work is voluntered time? 14:20 #dri-devel: < digetx> indeed, missed the dry-run option, thanks 14:20 -!- Moprius [~Thunderbi@177.51.37.59] has joined #radeon 14:20 -!- Moprius [~Thunderbi@177.51.37.59] has joined #wayland 14:21 #dri-devel: < daniels> cmeissl[m]: the client needs to receive etnaviv as the main device indeed, because etnaviv _is_ the main device - it's the fallback which is used for composition in case it's not possible to use planes, so the buffers always need to be accessible to etnaviv. I think the optimisation is substantially reworking the DRIScreen/pipe_screen/kmsro/etc integration so that we can pass preferred_device down to the driver layer, and it can 14:21 #dri-devel: < daniels> open kmsro if required 14:21 -!- Moprius [~Thunderbi@0002e253.user.oftc.net] has quit [] 14:21 -!- Moprius [~Thunderbi@0002e253.user.oftc.net] has quit [] 14:21 -!- mode/#freedesktop [+o daniels] by ChanServ 14:22 -!- mode/#freedesktop [-M] by daniels 14:22 -!- mode/#freedesktop [-o daniels] by daniels 14:22 #freedesktop: < daniels> pq: there we go 14:22 #wayland: < pq> DodoGTA, maybe kwin just immediately undoes what you do with xrandr? In the end, kwin decides what the primary output is anyway. 14:22 #freedesktop: < pq> \o/ 14:22 #freedesktop: < emersion> thanks! 14:23 -!- arsenm [~Adium@172.58.109.26] has joined #radeon 14:23 #freedesktop: < bentiss> karolherbst: the other problem is that if you want to hire someone to deal with that sort of spam problem: I will not be that person and I doubt you'll find skilled enough persons who can deal with what we technically need for an admin and who is agreeing to review all users to check if they are spam or not 14:24 #freedesktop: < karolherbst> ohh.. I didn't ask for a admin clicking the UI all the time 14:24 #freedesktop: < daniels> emersion: np 14:24 #wayland: < pq> xrandr is never the authoritative configuration tool, not even on Xorg. You need to have the DE specifically adapt to what you might change with xrandr - it's just that on Xorg, the DE cannot stop you from messing with xrandr. 14:24 #freedesktop: < karolherbst> but more like, checking what's the source and just block it all or something 14:24 #freedesktop: < karolherbst> or well.. do something sensible against spam 14:24 -!- arsenm1 [~Adium@172.58.27.45] has joined #radeon 14:24 -!- arsenm1 [~Adium@172.58.27.45] has quit [Read error: Connection reset by peer] 14:25 #freedesktop: < karolherbst> like you said that it's low prio for you to do such analysis 14:25 -!- molinari [~molinari@67.167.185.81.rev.sfr.net] has quit [Ping timeout: 480 seconds] 14:25 #wayland: < vsyrjala> kwin supposedly has https://wayland.app/protocols/kde-primary-output-v1 14:25 #freedesktop: < bentiss> karolherbst: since last Friday we had ~140 external accounts (pending approval), now the UI doesn't even want to give me the number, but it's more than 1000, over 3 days with a weekend 14:25 #wayland: < pq> well, "never" is an overstatement. On non-DE environments xrandr might be only thing driving the monitor configuration. 14:26 #wayland: < zzag> That's a deprecated protocol, but you shouldn't use neither kde-primary-output-v1 no kde-output-order-v1 14:26 #wayland: < zzag> nor* 14:26 -!- mbrost [~mbrost@192.55.54.55] has joined #dri-devel 14:26 -!- mbrost [~mbrost@192.55.54.55] has joined #intel-gfx 14:26 #wayland: < zzag> Those are for plasma 14:26 -!- mbrost [~mbrost@192.55.54.55] has quit [] 14:26 -!- mbrost [~mbrost@192.55.54.55] has quit [] 14:26 #freedesktop: < bentiss> so there is no way we can manually check them, and doing stats is going to be interesting... because out of these people, I doubt we have a majority of actual users 14:26 #intel-3d: < dolphin> gfxstrand: we are supposed to zero on discrete too 14:26 -!- mbrost [~mbrost@192.55.54.55] has joined #dri-devel 14:26 -!- mbrost [~mbrost@192.55.54.55] has joined #intel-gfx 14:26 #freedesktop: < bentiss> not bots I mean 14:26 #wayland: < zzag> You shouldn't use xrandr command to change the primary output either 14:27 #wayland: < pq> we can always rightfully blame the app, and that doesn't help the end user... 14:27 #freedesktop: < karolherbst> yeah.. but I can also suspect there is some backend stuff which could be done.. like shared IP lists, whatever else there is t combat spam in a more sensible way. I don't know, but I can suspect that an expert on this topic might know what to do 14:27 -!- arsenm [~Adium@172.58.109.26] has quit [Remote host closed the connection] 14:28 -!- molinari [~molinari@176-151-233-216.abo.bbox.fr] has joined #wayland 14:28 #freedesktop: < bentiss> honestly, I don't think IP blocklisting help: you can just use AWS and you have unlimitted IPs 14:28 #freedesktop: < karolherbst> well.. but no user will use any IP AWS would ever use 14:28 #freedesktop: < bentiss> replace with whatever cloud you want 14:28 #freedesktop: < karolherbst> so you can just block the entire range 14:28 #wayland: < zzag> pq: if you want a window to be shown on a particular output, change the relevant window geometry hints. changing the primary output may help you to achieve your goal, but one could argue that there are better options 14:28 #freedesktop: < karolherbst> block all clouds then 14:29 #freedesktop: < bentiss> but then you'll have users complaining because they have to use the cloud to work around any protection of it fits their process 14:29 #freedesktop: < karolherbst> VPN providers might be a more difficult thing to block 14:29 #freedesktop: < karolherbst> mhh yeah.. probably 14:29 #freedesktop: < bentiss> and we have valid users who think VPN is important 14:29 #freedesktop: < karolherbst> could also only do the new restrictions on IPs coming from the cloud 14:30 -!- kinkinkijkin [~kinkinkij@162.246.53.59] has quit [Quit: Leaving] 14:30 #wayland: < pq> DodoGTA, ^ 14:30 #freedesktop: < bentiss> same problem, people who believe it's important to be masked will do it from day 1 and will vocally complain that they have to use their true IP even once 14:30 #freedesktop: < karolherbst> but the initial point still stands: we don't know the source of the spam 14:30 -!- apinheiro [~infapi00@fanzine2.igalia.com] has quit [Ping timeout: 480 seconds] 14:30 #freedesktop: < karolherbst> so it's kind of mood to talk about it 14:30 #dri-devel: < DavidHeidelberg[m]> eric_engestrom: merge: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21518 ? 14:31 -!- tobiasjakobi [~tjakobi@dslb-088-068-118-062.088.068.pools.vodafone-ip.de] has joined #dri-devel 14:31 -!- tobiasjakobi [~tjakobi@dslb-088-068-118-062.088.068.pools.vodafone-ip.de] has quit [Remote host closed the connection] 14:31 #freedesktop: < karolherbst> but anyway, what's the discussion about now? we shouldn't consider paying an admin, because.... there might be nothing to do to fight spam? 14:31 #freedesktop: < bentiss> karolherbst: yeah, and furthermore gitlab doesn't have an ip blocklist in the sign-up settings. All we can do is block by domain 14:32 #freedesktop: < karolherbst> I'd say we should consider it, because it would also fix other problems 14:32 #dri-devel: < eric_engestrom> DavidHeidelberg[m]: yes, sorry I was off on friday for a long weekend and I haven't gotten around to that MR yet, but I'll add the r-b and marge in a minute 14:32 #dri-devel: < mupuf> DavidHeidelberg[m]: yeeeees! On it now :) 14:32 #freedesktop: < karolherbst> I'm not an admin and totally not an expert on fighting spam. If there is a chance to get somebody who knows what to do, even better 14:32 #dri-devel: < DavidHeidelberg[m]> all good news, I love this chat :D 14:32 #freedesktop: < bentiss> the discussion is more "as an admin, I'd like to share the burden of detrecting spam with every other maintainer involved in the community" 14:33 #dri-devel: < DavidHeidelberg[m]> eric_engestrom: hope you enjoyed the weekend to the 100% ;-) 14:33 #freedesktop: < karolherbst> yeah.. so we just spread around the initial problem of overworked admins 14:33 #freedesktop: < karolherbst> doesn't sound like a sustainable solution 14:33 -!- zehortigoza [~zehortigo@2607:f298:5:104b::d0e:d5ef] has quit [Remote host closed the connection] 14:33 -!- zehortigoza [~zehortigo@2607:f298:5:104b::d0e:d5ef] has quit [Remote host closed the connection] 14:33 -!- zehortigoza [~zehortigo@2607:f298:5:104b::d0e:d5ef] has quit [Remote host closed the connection] 14:33 #freedesktop: < karolherbst> something new will come up and the burden will only increase 14:34 #dri-devel: < DavidHeidelberg[m]> sse2 fixes got it, armv7 lto workaround awaits, android fix to be merged, mold fix in main branch should probably solve LTO fail when linking release build. Life is great. 14:34 #freedesktop: < bentiss> agree, and as long as we don't consider that there is a minimum of social invovled to onboard occasional contributors, we can not win that fight IMO 14:35 #dri-devel: < eric_engestrom> :D 14:35 #freedesktop: < karolherbst> right 14:37 -!- yuq825 [~yuq@180.152.11.27] has quit [] 14:37 -!- yuq825 [~yuq@180.152.11.27] has quit [] 14:38 #freedesktop: < bentiss> TBH, call me an old fart, but when I started working on opensource, the entry level was way higher: you had to find a way to clone the repo, work on it, then submit a patch by email without mangling it to even get the attention of maintainers. Now gitlab allows to fork and create MR in a few clicks, but sometime we got "drive-by" users who open a MR and never reply to the 14:38 #freedesktop: < bentiss> maintainer questions 14:38 -!- gtristan [~tristan@223.38.35.227] has quit [Remote host closed the connection] 14:39 #freedesktop: < karolherbst> well. the way I started was my creating random PRs 14:39 #freedesktop: < bentiss> so having people complaining that we are making it harder for contributors because they have to ask what they can do is very worrying to me 14:39 -!- gtristan [~tristan@223.38.35.227] has joined #freedesktop 14:39 #freedesktop: < karolherbst> ohh.. I compare with the baseline: github 14:39 #freedesktop: < bentiss> github as an army of admins 14:39 #freedesktop: < karolherbst> well 14:40 #freedesktop: < karolherbst> but from a contributors pov it's kind of what you'd expect 14:40 #radeon: < cheako> Venemo: I just watched a video on cognitive bias( https://www.youtube.com/watch?v=TT81fe2IobI ). I think the questions to ask is would ppl be open to this ffect I'm studying be the result of silicone or firmware? I don't have access to either of these, so I haven't been able to study them and I rely on others to do that work. 14:40 #freedesktop: < karolherbst> of course you can always compare against the one of the worst contenders, but.... 14:40 #freedesktop: < bentiss> when I was young, if you wanted to talk in a forum, you had to open a self presentation topic. This is no more what I'd like to have, just make sure we have a human in front of us 14:41 #freedesktop: < karolherbst> heh 14:41 #freedesktop: < karolherbst> never done that 14:41 #freedesktop: < alatiera> chatgpt, write me an introductory post for for an opensource newcomer 14:42 #freedesktop: < karolherbst> :3 14:42 #freedesktop: < karolherbst> yes, chatgpt will rescue us against stuff like that 14:43 #freedesktop: < karolherbst> chatgpt: talk to fdo maintainers to unluck my account :3 14:43 #radeon: < cheako> I couldn't find a CPP chat room that's populated this tod, anyone know where I can ask noob questions? I get this error https://github.com/cheako/gfxreconstruct/actions/runs/4282972079/jobs/7457915815#step:4:152 https://github.com/cheako/gfxreconstruct/commit/fcf4b840b5fca53dde519119dc404c8bc81dc074 14:43 #freedesktop: < karolherbst> (one should actually try that for ...) 14:43 #freedesktop: < alatiera> would make for pubicity 14:44 #freedesktop: < alatiera> no idea if it will be good or bad 14:44 #freedesktop: < karolherbst> same 14:44 #freedesktop: < karolherbst> but yeah.. chatgpt is probably the tool to get around the new restrictions 14:44 -!- kts [~kts@103.73.237.165] has joined #dri-devel 14:44 -!- kts [~kts@103.73.237.165] has joined #intel-gfx 14:44 -!- kts [~kts@103.73.237.165] has joined #intel-3d 14:44 -!- kts [~kts@103.73.237.165] has joined #wayland 14:45 -!- gtristan [~tristan@223.38.35.227] has quit [Remote host closed the connection] 14:46 -!- gtristan [~tristan@223.38.35.227] has joined #freedesktop 14:46 #freedreno: < robclark> krh: other than completely failing at the goal of not having to re-write everything, it's a great idea :-P 14:47 #freedreno: < Hazematman> Hey, is anyone here doing any work with freedreno using the MSM driver on android? I'm currently getting a kgsl backend working and I'm getting a bunch of permission errors flooding logcat from "android.hardware.camera.provider" when it calls `property_get` in `os_get_android_option`. 14:47 #freedreno: < Hazematman> I'm curious if any other android setups are getting the same logcat spam from the camera provider. 14:47 #freedreno: < Hazematman> In my changes right now I added some code to get the process name and if its the camera provider I return early to avoid logcat spam. I don't think this is a good general solution, so I'm hoping to get some input from someone who is a little more experienced with android who might have a better idea on how I can handle this problem 14:48 -!- jkrzyszt [~jkrzyszt@134.191.221.86] has joined #intel-gfx 14:48 -!- jkrzyszt [~jkrzyszt@134.191.221.86] has joined #dri-devel 14:51 #wayland: < DodoGTA> zzag: I've tried to change the position window rule in KDE but that does nothing in fullscreen mode 14:51 #freedesktop: < bentiss> daniels: https://gitlab.freedesktop.org/freedesktop/helm-gitlab-omnibus/-/commit/53d36d73031f67428837062c04b60853a1024147 -> looks like it accepted my push, so we are good to go? :) 14:51 #freedesktop: < bentiss> I mean it's already deployed 14:52 #freedreno: < robclark> hmm, if some processes are not permitted to call `property_get()`.. that is unfortunate.. I guess we could add a build option to disable that path, but that would also mean you couldn't use setprop as alternative to env vars for mesa debug options 14:52 #freedreno: < robclark> I've not seen that problem on CrOS (android P or R) fwiw 14:54 -!- Paul33 [~Paul33@mob-5-91-106-99.net.vodafone.it] has joined #nouveau 14:54 -!- Paul33 [~Paul33@mob-5-91-106-99.net.vodafone.it] has joined #wayland 14:54 #freedreno: < konradybcio> Hazematman: any related selinux denials in dmesg, maybe? 14:54 #intel-3d: < gfxstrand> dolphin: No argument here. :) It just seems like the kind of thing that could have gotten deleted since I left. 😅 14:55 #dri-devel: < cmeissl[m]> daniels: oh, that doesn't sound like the easiest thing for someone still pretty unfamiliar with the inner workings of mesa. but, yes, using the target tranche device sounds like the best solution. out of curiosity I patched loader_get_render_node to return the primary node if no render node could be found and changed the feedback in the compositor to use card1 as the main device. Both paths, scan-out and composition, still work. 14:55 #freedreno: < robclark> also, maybe `property_get()` returns some permission error that could tell mesa to stop trying? 14:56 #freedreno: < Hazematman> robclark: that's a good point, let me check the return code 14:57 #radeon: < Venemo> cheako: I don't understand what you are asking, sorry 14:59 #freedreno: < Hazematman> At the time I get selinux avc denied error... (full message at ) 14:59 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has joined #radeon 14:59 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has joined #dri-devel 14:59 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has joined #freedesktop 14:59 -!- mbrost_ [~mbrost@192.55.54.55] has joined #intel-gfx 14:59 -!- mbrost_ [~mbrost@192.55.54.55] has joined #dri-devel 14:59 #wayland: < wlb> wayland Issue #360 opened by wentbackward (wentbackward) HP Pointing Stick Issue https://gitlab.freedesktop.org/wayland/wayland/-/issues/360 15:02 #freedreno: < Hazematman> doesn't look like property_get returns an error code directly :( https://android.googlesource.com/platform/system/core/+/master/libcutils/include/cutils/properties.h#42 15:03 #freedreno: < konradybcio> try booting with androidboot.selinux=permissive 15:03 #wayland: < wlb> weston Merge request !1178 opened by Michael Olbrich (mol) compositor/text-backend: use xzalloc everywhere https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1178 15:03 #freedreno: < konradybcio> this is a security compromise btw, if it's not obvious 15:03 #wayland: < wlb> wayland Issue #360 closed \o/ (HP Pointing Stick Issue https://gitlab.freedesktop.org/wayland/wayland/-/issues/360) 15:03 -!- fxkamd [~Thunderbi@lnsm2-torontoxn-142-116-149-103.dsl.bell.ca] has quit [] 15:03 -!- fxkamd [~Thunderbi@lnsm2-torontoxn-142-116-149-103.dsl.bell.ca] has quit [] 15:04 #freedreno: < Hazematman> konradybcio: I'd need to build my own image to do that correct? I'm currently using the official userdebug builds of aosp on my pixel 4a. Not building my own image 15:04 #freedreno: < konradybcio> fastboot -c cmdline should work, i believe 15:04 #freedreno: < konradybcio> get your current cmdline from /proc/cmdline and prepend this selinux thing 15:04 -!- mbrost [~mbrost@192.55.54.55] has quit [Ping timeout: 480 seconds] 15:04 -!- mbrost [~mbrost@192.55.54.55] has quit [Ping timeout: 480 seconds] 15:04 #freedesktop: < daniels> bentiss: hahaha nice :) sounds great 15:04 #freedreno: < konradybcio> i suppose you have a boot image to feed to fastboot? 15:05 #radeon: < cheako> I get the feeling that the applications are seen as a likely cause. That could be, even though there is evidence that doesn't support this conclusion. As a test I've been trying to use gfxrc, but the driver segfaults with that. To debug it(the driver/gfxrc combo) I've tried to build a debug version of gfxrc, but I'm stuck because cpp doesn't work at my skill level. 15:05 #wayland: < DodoGTA> So how should native Wayland toolkits/apps pick on which screen to run in fullscreen mode? 15:06 #freedreno: < Hazematman> I don't think I do. I used the android flash tool to flash the image directly (https://flash.android.com) 15:07 #freedreno: < konradybcio> what's your phone? 15:07 #freedreno: < konradybcio> i assume a pixel of nexus of some kind? 15:07 #wayland: < wlb> weston Issue #727 opened by Kim Crow (kimcrow) 4 Gift Exchange Ideas for Big Families https://gitlab.freedesktop.org/wayland/weston/-/issues/727 15:08 #freedreno: < Hazematman> Pixel 4a 15:08 #freedreno: < konradybcio> google has a page with factory images, download the one matching your android release and use the boot.img from there 15:08 #wayland: < emersion> ah nice 15:09 #wayland: < DodoGTA> When you spam it (osu! reference) 15:09 -!- Aison [~Ivo@2a02:168:200f:100::1:1] has joined #radeon 15:09 #freedreno: < Hazematman> I tested that before, but the issue I had there was that those images didn't let me remount the system file system as RW to copy over the freedreno driver over the qualcomm ones 15:10 #wayland: < wlb> weston Merge request !1179 opened by Michael Olbrich (mol) ivi-layout: simplify API https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1179 15:10 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has joined #etnaviv 15:10 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has joined #dri-devel 15:11 #freedreno: < danylo> Anyway, setting it to permissive would just solve the issue on that particular device. 15:11 -!- fab [~fab@134.214.236.142] has quit [Quit: fab] 15:11 #freedreno: < konradybcio> did you use magisk then? 15:11 #wayland: < pq> DodoGTA, I don't think native Wayland apps do. The compositor does. 15:11 #freedreno: < konradybcio> it should leave you a patched boot.img in /sdcard/Downloads or /sdcard 15:11 #wayland: < zzag> DodoGTA: huh, it might be a bug. Please file a bug report. Note that there's also a screen rule 15:12 #freedreno: < danylo> Also won't adb shell setenforce 0 do the work? 15:12 #radeon: < Aison> hello :-) I'm using kernel 6.2.0-rc7 for my VEGA64 and it works fine (also with MST). Older kernel versions like 6.1.X didn't work 15:12 #freedreno: < konradybcio> Danylo: i think that only works on >=userdebug builds 15:12 -!- gtristan [~tristan@223.38.35.227] has quit [Ping timeout: 480 seconds] 15:12 #wayland: < zzag> pq: xdg_toplevel.set_fullscreen takes an output hint 15:12 #freedreno: < konradybcio> but may be worth a try 15:12 #freedreno: < Hazematman> No i'm not using Magisk. The userdebug builds (that I can access from the android flash tool from google) allow you remount the system partition 15:12 #wayland: < DodoGTA> zzag: I also tried that with values set at 0 and 1 (no difference) 15:12 #freedreno: < konradybcio> oh then just run this command that Danylo posted 15:12 #wayland: < pq> yeah, it takes a hint. That's all. 15:12 #freedreno: < Hazematman> actually it does seem that just setenforce 0 works 15:13 #radeon: < Aison> now I compiled 6.2.0+ and there I have only black screen. Are there any changes to amdgpu driver?!? 15:13 #freedreno: < Hazematman> thanks guys :) 15:13 #wayland: < pq> If an app uses that hint, the app really needs to have a way to change that somehow too. 15:14 #wayland: < pq> It doesn't mean apps should usually set that hint. 15:14 #freedreno: < danylo> anyway, that doesn't answer the core question of how to prevent spam in every case 15:15 #freedreno: < konradybcio> adb logcat | grep -v /s 15:17 #freedesktop: < bentiss> daniels: I have the following regex for new internal users by default: @(amd.com|collabora.com|intel.com|nvidia.com|redhat.com), in https://gitlab.freedesktop.org/admin/application_settings/general#js-account-settings feel free to extend it a bit 15:17 #freedesktop: < daniels> bentiss: that's awesome, thanks - I don't expect to have time to look at much anything though 15:18 #freedesktop: < bentiss> daniels: ok, then we'll see how many reports we get from people and adjust as it goes 15:18 #freedreno: < Hazematman> danylo: I'm only seeing it from the camera provider. If someone were to actually use this in a production environment I think they would need to modify the selinux rules to allow the camera provider to read permissions. 15:18 #freedreno: < Hazematman> I assume you should be able to do that if you're building the Android ROM image yourself (That's just a guess, I don't know that much about selinux/android) 15:19 #freedreno: < danylo> fair enough 15:20 #freedreno: < Hazematman> s/permissions/properties/ 15:20 #freedreno: < konradybcio> yes you can do it, selinux rules are shipped as part of your android device tree 15:21 #radeon: < Venemo> Aison: possibly, agd5f may know something about that 15:22 #radeon: < agd5f> Aison, are the firmwares available in your initrd (if you are using one)? 15:22 #radeon: < Aison> I have no initrd 15:22 #radeon: < Aison> using gentoo here without 15:23 #radeon: < agd5f> Are they compiled into the kernel properly in that case? 15:25 #radeon: < agd5f> assuming they are available on the filesystem, you can add modprobe.blacklist=amdgpu on the kernel command line in grub, and then run modprobe amdgpu after the system boots 15:25 #radeon: < agd5f> assuming you are building amdgpu as a module 15:25 #radeon: < Aison> do I have to explicitly? because my firmware files are located at /lib/firmware 15:25 #radeon: < Aison> yes, it's a module 15:26 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has quit [Ping timeout: 480 seconds] 15:26 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has quit [Ping timeout: 480 seconds] 15:26 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has quit [Ping timeout: 480 seconds] 15:26 #radeon: < _ds_> If your firmware isn't bundled into the kernel then you do need amdgpu as a module. In that case, you'll also need basic framebuffer console support compiled into the kernel 15:26 #radeon: < _ds_> (AIUI, anyway) 15:27 #radeon: < Aison> framebuffer console is compiled in 15:28 #radeon: < Aison> well, to be precisous: the framebuffer console works. But as soon as X is started I have a black screen 15:28 #radeon: < Aison> maybe I should login with my 2nd machine and check the logs 15:29 #radeon: < _ds_> Can you switch to a text console? 15:29 #radeon: < Aison> no, it remains black 15:30 -!- orbea [~orbea@000289e2.user.oftc.net] has quit [Quit: You defeated orbea! 2383232 XP gained!] 15:30 -!- orbea [~orbea@000289e2.user.oftc.net] has quit [Quit: You defeated orbea! 2383232 XP gained!] 15:30 -!- orbea [~orbea@000289e2.user.oftc.net] has quit [Quit: You defeated orbea! 2383232 XP gained!] 15:30 -!- orbea [~orbea@000289e2.user.oftc.net] has quit [Quit: You defeated orbea! 2383232 XP gained!] 15:31 -!- orbea [~orbea@000289e2.user.oftc.net] has joined #d3d9 15:31 -!- orbea [~orbea@000289e2.user.oftc.net] has joined #dri-devel 15:31 -!- orbea [~orbea@000289e2.user.oftc.net] has joined #nouveau 15:31 -!- orbea [~orbea@000289e2.user.oftc.net] has joined #radeon 15:33 #wayland: < pq> swick[m], btw. I'm currently improving the wp_image_description events to be more like the respective factory requests. 15:33 #wayland: < pq> till tomorrow \o. 15:33 #wayland: < swick[m]> o/ 15:38 -!- mmu_man [~revol@82-65-227-82.subs.proxad.net] has quit [Ping timeout: 480 seconds] 15:40 #freedesktop: < jenatali> bentiss: Would be nice to add microsoft.com to that too :) 15:40 #freedesktop: < bentiss> jenatali: sure 15:41 #freedesktop: < bentiss> jenatali: done 15:41 #freedesktop: < bentiss> FWIW, I also added kernel.org previously 15:41 #freedesktop: < jenatali> Thanks! 15:42 #freedesktop: < bentiss> heh, I just realized what we should tell our users complaining that they can not fork: "just get a kernel.org email address (it's easy, really), then register a new gitlab account" :) (just jocking) 15:43 #freedesktop: < bentiss> joking 15:43 #freedesktop: < bentiss> sorry, can't type today :/ 15:44 -!- mbrost__ [~mbrost@192.55.54.55] has joined #intel-gfx 15:44 -!- mbrost__ [~mbrost@192.55.54.55] has joined #dri-devel 15:45 #freedesktop: < eric_engestrom> bentiss: @igalia.com too? :) 15:45 #freedesktop: < bentiss> eric_engestrom: sure, and done :) 15:46 #freedesktop: < eric_engestrom> thx :P 15:46 -!- mbrost_ [~mbrost@192.55.54.55] has quit [Ping timeout: 480 seconds] 15:46 -!- mbrost_ [~mbrost@192.55.54.55] has quit [Ping timeout: 480 seconds] 15:47 -!- kzd [~kzd@static-198-54-130-132.cust.tzulo.com] has joined #radeon 15:47 -!- kzd [~kzd@static-198-54-130-132.cust.tzulo.com] has joined #dri-devel 15:47 -!- fab [~fab@bellet.info] has joined #dri-devel 15:49 -!- mmu_man [~revol@188410969.box.freepro.com] has joined #nouveau 15:54 #freedesktop: < robclark> bentiss: @google.com and @chromium.org? (although I guess a lot of use other email addrs for upstream stuff) 15:55 #freedesktop: < bentiss> robclark: sure, and done :) 15:56 #freedesktop: < robclark> thx 15:57 #freedesktop: < mupuf> bentiss: thanks for starting the regex for internal users! 16:01 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has joined #radeon 16:01 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has joined #freedesktop 16:01 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has joined #dri-devel 16:01 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has joined #nouveau 16:01 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has joined #intel-3d 16:01 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has joined #intel-gfx 16:01 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has joined #lima 16:01 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has joined #etnaviv 16:01 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has joined #wayland 16:01 -!- nchery [~nchery@134.134.139.80] has quit [Read error: Connection reset by peer] 16:01 -!- nchery [~nchery@134.134.139.80] has quit [Read error: Connection reset by peer] 16:01 -!- nchery [~nchery@134.134.139.80] has quit [Read error: Connection reset by peer] 16:06 -!- cool110_ [~mark@0002e01f.user.oftc.net] has joined #wayland 16:06 -!- Deluxef [~Deluxe@212.4.150.151] has joined #radeon 16:08 -!- cool110 [~mark@0002e01f.user.oftc.net] has quit [Remote host closed the connection] 16:08 -!- Paul33_ [~Paul33@mob-5-91-111-58.net.vodafone.it] has joined #nouveau 16:08 -!- Paul33_ [~Paul33@mob-5-91-111-58.net.vodafone.it] has joined #wayland 16:09 -!- Deluxef [~Deluxe@212.4.150.151] has quit [Remote host closed the connection] 16:10 -!- mmu_man [~revol@188410969.box.freepro.com] has quit [Ping timeout: 480 seconds] 16:11 -!- Deluxef [~Deluxe@212.4.150.151] has joined #radeon 16:13 -!- bmodem [~Thunderbi@134.134.139.87] has quit [Ping timeout: 480 seconds] 16:13 -!- bmodem [~Thunderbi@134.134.139.87] has quit [Ping timeout: 480 seconds] 16:14 -!- Duke`` [~plop@2a01cb0007977800eb0dededc85d5cc6.ipv6.abo.wanadoo.fr] has joined #dri-devel 16:14 -!- Duke`` [~plop@2a01cb0007977800eb0dededc85d5cc6.ipv6.abo.wanadoo.fr] has joined #intel-gfx 16:15 -!- Paul33 [~Paul33@mob-5-91-106-99.net.vodafone.it] has quit [Ping timeout: 480 seconds] 16:15 -!- Paul33 [~Paul33@mob-5-91-106-99.net.vodafone.it] has quit [Ping timeout: 480 seconds] 16:15 -!- devilhorns [~devilhorn@2601:80:c980:7400:3a00:25ff:fe4e:1c9a] has quit [] 16:15 -!- devilhorns [~devilhorn@2601:80:c980:7400:3a00:25ff:fe4e:1c9a] has quit [] 16:16 #freedesktop: < bentiss> mupuf: should I add valve.com or you don't expect people from this company to create an account? 16:16 #freedesktop: < mupuf> I can add it, but I doubt this is gonna be a lot of people :D 16:16 #freedesktop: < bentiss> heh, OK :) 16:17 #freedesktop: < mupuf> done 16:17 #freedesktop: < bentiss> thx 16:17 -!- sparky4 [~sparky4@hutcheson-192.resnet.latech.edu] has joined #nouveau 16:17 -!- fjdegroo [~fjdegroo@134.134.139.71] has joined #intel-3d 16:20 #freedesktop: < ishitatsuyuki> I think it's @valvesoftware.com fwiw 16:21 -!- zehortigoza [~zehortigo@2607:f298:5:104b::d0e:d5ef] has joined #dri-devel 16:21 -!- zehortigoza [~zehortigo@2607:f298:5:104b::d0e:d5ef] has joined #intel-3d 16:21 -!- zehortigoza [~zehortigo@2607:f298:5:104b::d0e:d5ef] has joined #intel-gfx 16:21 -!- Deluxef [~Deluxe@212.4.150.151] has quit [Remote host closed the connection] 16:25 #dri-devel: < karolherbst> could somebody look at why gc2000_piglit times out 16:26 #dri-devel: < karolherbst> probably serial console spam.. anyway, would be nice if somebody looks into it 16:26 #dri-devel: < karolherbst> zmike: already aware of the UnexpectedPass with zink? 16:26 #dri-devel: < zmike> what 16:26 #dri-devel: < karolherbst> https://gitlab.freedesktop.org/mesa/mesa/-/jobs/37035888#L3220 16:27 -!- floof58 is now known as Guest6078 16:27 -!- floof58 is now known as Guest6078 16:27 #dri-devel: < karolherbst> seeing this randomly pop up in a few MRs, but I can also send an MR 16:27 -!- floof58 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has joined #radeon 16:27 -!- floof58 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has joined #wayland 16:27 #dri-devel: < karolherbst> just wondering if anybody already sent an MR 16:29 #dri-devel: < zmike> no, never seen those 16:29 #dri-devel: < MrCooper> UnexpectedPass should arguably cause the job to fail 16:29 #dri-devel: < zmike> I don't usually look at the full run results 16:29 #dri-devel: < karolherbst> yeah.. I mean, yes, jobs fail, that's why I'm bringing it up 16:29 #dri-devel: < karolherbst> I'll submit an MR 16:29 #dri-devel: < zmike> I wasn't aware that the full run occurred on wayland 16:29 -!- mbrost__ [~mbrost@192.55.54.55] has quit [Remote host closed the connection] 16:29 -!- mbrost__ [~mbrost@192.55.54.55] has quit [Remote host closed the connection] 16:29 -!- mbrost__ [~mbrost@192.55.54.55] has joined #intel-gfx 16:29 -!- mbrost__ [~mbrost@192.55.54.55] has joined #dri-devel 16:30 #dri-devel: < zmike> karolherbst: you can ack and merge it directly 16:30 #dri-devel: < zmike> add my ack* 16:30 #dri-devel: < karolherbst> my fear is, it's just some flakes, but I'll see how well that goes 16:30 #dri-devel: < daniels> (specifically, add it to flakes, not passes) 16:30 #dri-devel: < daniels> as for gc2000, those jobs are manual for a reason - they're not expected to work all the time 16:30 #freedesktop: < Ford_Prefect> bentiss: sorry if I missed something, but what is this email domain allowlist for? 16:31 -!- Guest6078 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has quit [Ping timeout: 480 seconds] 16:31 -!- Guest6078 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has quit [Ping timeout: 480 seconds] 16:31 #dri-devel: < karolherbst> ohhh 16:31 #freedesktop: < bentiss> Ford_Prefect: if you are on tis allowlist, wen you create a new gitlab account on fd.o, you will be marked as internal and will allowed to create forks/projects without having to ask 16:31 #dri-devel: < karolherbst> it's all multi_context .. duh 16:31 #dri-devel: < karolherbst> sooo.. 16:32 #dri-devel: < karolherbst> something has a threading bug 16:32 #freedesktop: < bentiss> Ford_Prefect: so no changes in current accounts, just future ones 16:32 -!- pallavim [~pallavim@192.55.55.52] has joined #intel-gfx 16:32 -!- pallavim [~pallavim@192.55.55.52] has joined #dri-devel 16:32 #freedesktop: < Ford_Prefect> bentiss: ah, @asymptotic.io and @centricular.com too then probably? 16:32 #dri-devel: < daniels> shocked 16:32 #dri-devel: < karolherbst> very much so 16:33 #dri-devel: < karolherbst> best part: "warnings from the kernel" yeah I can already figure where that bug lives 16:33 #freedesktop: < bentiss> Ford_Prefect: sure, and done :) 16:34 #freedesktop: < Ford_Prefect> thank you! 16:34 #dri-devel: < karolherbst> I'll move the entire section into flakes... 16:37 #dri-devel: < karolherbst> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21561 16:43 -!- mbrost__ [~mbrost@192.55.54.55] has quit [Ping timeout: 480 seconds] 16:43 -!- mbrost__ [~mbrost@192.55.54.55] has quit [Ping timeout: 480 seconds] 16:44 -!- mmu_man [~revol@188410969.box.freepro.com] has joined #nouveau 16:44 #dri-devel: < daniels> karolherbst: danke! 16:44 #dri-devel: < eric_engestrom> karolherbst: if you leave them in the fails as well, that means they only get reported as flakes when they pass, which I think is rare 16:45 #dri-devel: < eric_engestrom> (aka less #zink-ci spam) 16:46 -!- apinheiro [~infapi00@78.0.27.77.dynamic.reverse-mundo-r.com] has joined #dri-devel 16:48 #freedreno: < cwabbott> apparently mad.f32 and mad.f16 aren't supported with the scalar ALU?!? 16:48 #freedreno: < cwabbott> apparently no fused multiply-add for you in the early preamble 16:51 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has joined #radeon 16:51 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has joined #dri-devel 16:51 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has joined #freedesktop 16:52 -!- genpaku_ [~genpaku@107.191.100.185] has quit [Read error: Connection reset by peer] 16:52 -!- genpaku_ [~genpaku@107.191.100.185] has quit [Read error: Connection reset by peer] 16:52 -!- genpaku_ [~genpaku@107.191.100.185] has quit [Read error: Connection reset by peer] 16:52 -!- genpaku_ [~genpaku@107.191.100.185] has quit [Read error: Connection reset by peer] 16:52 -!- genpaku_ [~genpaku@107.191.100.185] has quit [Read error: Connection reset by peer] 16:52 -!- genpaku_ [~genpaku@107.191.100.185] has quit [Read error: Connection reset by peer] 16:52 -!- genpaku_ [~genpaku@107.191.100.185] has quit [Read error: Connection reset by peer] 16:53 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has quit [Ping timeout: 480 seconds] 16:53 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has quit [Ping timeout: 480 seconds] 16:54 #freedreno: < robclark> I guess that applies to all cat3 instructions? 16:55 -!- aravind [~aravind@134.134.137.86] has quit [Ping timeout: 480 seconds] 16:55 -!- aravind [~aravind@134.134.137.86] has quit [Ping timeout: 480 seconds] 16:56 -!- genpaku [~genpaku@107.191.100.185] has joined #dri-devel 16:56 -!- genpaku [~genpaku@107.191.100.185] has joined #wayland 16:56 -!- genpaku [~genpaku@107.191.100.185] has joined #freedesktop 16:56 -!- genpaku [~genpaku@107.191.100.185] has joined #radeon 16:56 -!- genpaku [~genpaku@107.191.100.185] has joined #nouveau 16:56 -!- genpaku [~genpaku@107.191.100.185] has joined #intel-gfx 16:56 -!- genpaku [~genpaku@107.191.100.185] has joined #intel-3d 16:59 -!- vliaskov [~vliaskov@dynamic-077-191-055-225.77.191.pool.telefonica.de] has quit [Remote host closed the connection] 16:59 -!- vliaskov [~vliaskov@dynamic-077-191-055-225.77.191.pool.telefonica.de] has quit [Remote host closed the connection] 17:00 -!- stuart [~jssummer@192.55.54.52] has joined #intel-gfx 17:00 -!- stuart [~jssummer@192.55.54.52] has joined #dri-devel 17:01 -!- jsa [~jsaarine@134.191.221.82] has quit [] 17:04 -!- cool110_ [~mark@0002e01f.user.oftc.net] has quit [Remote host closed the connection] 17:05 -!- cool110 [~mark@0002e01f.user.oftc.net] has joined #wayland 17:05 -!- kts [~kts@103.73.237.165] has quit [Quit: Konversation terminated!] 17:05 -!- kts [~kts@103.73.237.165] has quit [Quit: Konversation terminated!] 17:05 -!- kts [~kts@103.73.237.165] has quit [Quit: Konversation terminated!] 17:05 -!- kts [~kts@103.73.237.165] has quit [Quit: Konversation terminated!] 17:08 -!- mmu_man [~revol@188410969.box.freepro.com] has quit [Ping timeout: 480 seconds] 17:09 #wayland: < kennylevinsen> DodoGTA: the value is a wl_output object ID, not an output number 17:13 -!- KnM_ [~mdnavare@c-73-157-143-109.hsd1.or.comcast.net] has quit [Ping timeout: 480 seconds] 17:16 #freedreno: < flto> cwabbott: AFAIK there isn't a separate ALU unit for scalar ops and cat3 not working is because the 2nd source of cat3 can't be a constant (SGPR and constants use the same storage) 17:16 #freedreno: < cwabbott> flto: nope, there is 17:16 #freedreno: < flto> how do you know there is? 17:17 -!- mmu_man [~revol@188410969.box.freepro.com] has joined #nouveau 17:18 #freedreno: < cwabbott> when you have a cat2-cat3 op that writes to a shared register, you need (ss) when reading from its result, unlike a normal ALU op, and all the normal restrictions go away 17:18 #freedreno: < cwabbott> you can read unlimited shared sources, but can't read "normal" sources 17:19 -!- nukelet_ [~quassel@189.111.57.221] has quit [] 17:19 #freedreno: < flto> that's because writing to shared registers is writing to the constant ram, so its similar to the store constant cat6 instruction which also needs (ss) 17:19 #freedreno: < cwabbott> only mov can read shared and write to normal, as it turns out there's a special third ALU for "uniformizing" ALU ops used by readlane() and readfirstlane() 17:20 -!- djbw [~djbw@192.55.55.56] has joined #dri-devel 17:22 #wayland: < DodoGTA> kennylevinsen: Are those object IDs random? 17:23 #radeon: < cheako> I found the bug in gfxrc, it's not calling create fence anywhere and just using `0` as a `VkFence`. 17:23 -!- jkrzyszt [~jkrzyszt@134.191.221.86] has quit [Remote host closed the connection] 17:23 -!- jkrzyszt [~jkrzyszt@134.191.221.86] has quit [Remote host closed the connection] 17:24 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has joined #etnaviv 17:24 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has joined #dri-devel 17:24 -!- kzd_ [~kzd@static-198-54-130-84.cust.tzulo.com] has joined #radeon 17:24 -!- kzd_ [~kzd@static-198-54-130-84.cust.tzulo.com] has joined #dri-devel 17:26 -!- drod [~ldm@ip-95-220-105-14.bb.netbynet.ru] has joined #lima 17:27 #freedreno: < cwabbott> flto: on a650+ cat2-cat3 ops that write shared registers don't need (ss) between them 17:28 #freedreno: < cwabbott> they only need (ss) when an ALU op not writing to shared reads it 17:28 -!- smiles [~smiles@2409:8a00:db0:5800:4036:9290:4c47:439b] has quit [Ping timeout: 480 seconds] 17:29 #freedreno: < cwabbott> that only makes sense if there is a scalar ALU 17:29 -!- lmaoman [~lmaoman@45.63.97.131] has quit [] 17:30 -!- Supersaiyan_IV [~QAM@85.228.153.205] has quit [Read error: Connection reset by peer] 17:30 -!- Supersaiyan_IV [~QAM@85.228.153.205] has quit [Read error: Connection reset by peer] 17:31 -!- kzd [~kzd@static-198-54-130-132.cust.tzulo.com] has quit [Ping timeout: 480 seconds] 17:31 -!- kzd [~kzd@static-198-54-130-132.cust.tzulo.com] has quit [Ping timeout: 480 seconds] 17:32 #dri-devel: < marex> I am curious, there is a patchset which adds support for feeding multiple encoders->bridges from single crtc for lcdif driver , is that something that one can really do ? 17:32 #dri-devel: < marex> mripard: ^ 17:32 -!- kinkinkijkin [~kinkinkij@162.246.53.59] has joined #radeon 17:32 #dri-devel: < marex> my understanding is they read the same base plan using crtc and then pump it out into some "tee" which feeds the encoders and then bridges, all of them with the same data, at the same time 17:33 #dri-devel: < mareko> zmike: both 17:33 #dri-devel: < marex> I am a bit hesitant to review that stuff 17:34 #freedreno: < flto> cwabbott: it doesn't necessarily mean that, if this extra scalar ALU existed there would be perfcounters for it and these "scalar" ALU instructions wouldn't count towards the normal ALU perfcounters 17:34 #dri-devel: < mripard> I have no idea whether the hardware is capable to do it 17:34 #dri-devel: < mripard> but KMS definitely can 17:34 #dri-devel: < zmike> mareko: ok, I am awaiting your followup with bated breath 17:34 #freedreno: < cwabbott> there's really no other good explanation for it, though 17:35 #dri-devel: < mripard> https://elixir.bootlin.com/linux/latest/source/include/drm/drm_encoder.h#L151 17:35 #dri-devel: < marex> mripard: the hardware can do it 17:35 -!- Paul33__ [~Paul33@mob-5-91-111-58.net.vodafone.it] has joined #nouveau 17:35 -!- Paul33__ [~Paul33@mob-5-91-111-58.net.vodafone.it] has joined #wayland 17:35 #dri-devel: < marex> mripard: it is the first time software needs to do it 17:35 #dri-devel: < marex> at least on imx scanout engines as far as I can tell 17:36 #freedreno: < robclark> might be worth trying to dump a7xx perfcntr names... if there are new counters, presumably they would have remembered to include them for a7xx blob 17:37 #dri-devel: < marex> https://patchwork.freedesktop.org/series/113210/ its this series 17:37 #radeon: < cheako> Timur: I'm guessing that should be the expectation for switching out foundational components, like GnomeShell vs i3 or wayland vs x11. That things can/do break in such spectacular ways testing the original assumption is impossible. I am suggesting this method be reserved as a last resort or for specific reasons, and not something done early in the workflow. 17:38 -!- Paul33__ [~Paul33@mob-5-91-111-58.net.vodafone.it] has quit [] 17:38 -!- Paul33__ [~Paul33@mob-5-91-111-58.net.vodafone.it] has quit [] 17:41 -!- Paul33_ [~Paul33@mob-5-91-111-58.net.vodafone.it] has quit [Ping timeout: 480 seconds] 17:41 -!- Paul33_ [~Paul33@mob-5-91-111-58.net.vodafone.it] has quit [Ping timeout: 480 seconds] 17:42 -!- ximion [~ximion@ip-176-199-211-108.um44.pools.vodafone-ip.de] has joined #freedesktop 17:42 -!- jhli_ [~jhli@137.22.168.34.bc.googleusercontent.com] has quit [Remote host closed the connection] 17:42 -!- jhli_ [~jhli@137.22.168.34.bc.googleusercontent.com] has quit [Remote host closed the connection] 17:42 -!- jhli_ [~jhli@137.22.168.34.bc.googleusercontent.com] has quit [Remote host closed the connection] 17:46 #dri-devel: < javierm> robclark, danvet: what if instead of adding a CONFIG_DRM_VIRTIO_GPU_KMS kconfig symbol, the driver is changed to only disable the KMS part with "nomodeset" ? 17:46 #dri-devel: < javierm> something like the following (untested) patch? https://paste.centos.org/view/raw/921ca0a4 17:46 -!- unerlige1 [~unerlige@134.134.139.80] has left #dri-devel [] 17:46 -!- unerlige1 [~unerlige@134.134.139.80] has left #intel-gfx [] 17:46 -!- unerlige [~unerlige@192.55.55.54] has joined #intel-gfx 17:46 -!- unerlige [~unerlige@192.55.55.54] has joined #dri-devel 17:46 #dri-devel: < javierm> that way you could just boot your guest VM with virtio-gpu.modeset=0 or nomodeset 17:47 #dri-devel: < danvet> yeah that might be a notch cleaner solution for the one-off-custom-built-distro case 17:48 #dri-devel: < danvet> it won't work in general, e.g. if you also pass through an actual virtualized display and not virtio-wayland 17:48 -!- jhli [~jhli@137.22.168.34.bc.googleusercontent.com] has joined #intel-gfx 17:48 -!- jhli [~jhli@137.22.168.34.bc.googleusercontent.com] has joined #dri-devel 17:48 -!- jhli [~jhli@137.22.168.34.bc.googleusercontent.com] has joined #intel-3d 17:48 #dri-devel: < robclark> hmm, I guess that fits the name, but diverges a bit on how other drivers interpret nomodeset 17:48 #dri-devel: < danvet> since that would then also get disabled 17:48 #dri-devel: < danvet> robclark, i915 did it like that in the good old days of ums gem support :-) 17:48 #dri-devel: < javierm> robclark: not really, in fact many drivers only disable KMS with nomodeset 17:49 -!- unerlige [~unerlige@192.55.55.54] has left #dri-devel [] 17:49 -!- unerlige [~unerlige@192.55.55.54] has left #intel-gfx [] 17:49 #dri-devel: < javierm> robclark: in fact, DRM only drivers just ignore that option 17:49 #dri-devel: < danvet> yeah plus that 17:49 #dri-devel: < robclark> hmm, well, I could *also* possibly add modparam option.. but the build option still works best for us 17:50 -!- unerlige [~unerlige@192.55.55.54] has joined #intel-gfx 17:50 -!- unerlige [~unerlige@192.55.55.54] has joined #dri-devel 17:50 #dri-devel: < javierm> robclark: right, not strong opinion for me. I just wanted to point out that there could be an alternative approach :) 17:51 #dri-devel: < javierm> regardless, it would be good if all drivers only disable KMS with nomodeset instead of just failing to probe 17:52 #dri-devel: < robclark> the build option is less subtle, and that makes it easier for folks triaging bug bounty program reports 17:53 #dri-devel: < anholt_> sergi: what's the deal with the piglit uprev mrs being testonly and getting closed? I would really like to see piglit updated, but I haven't done it because you're clearly working on it, but you keep closing them. 17:54 -!- jarthur [~jarthur@2603-8080-1500-1a3e-1d81-4b50-7973-8a46.res6.spectrum.com] has quit [Ping timeout: 480 seconds] 17:54 -!- jarthur [~jarthur@2603-8080-1500-1a3e-1d81-4b50-7973-8a46.res6.spectrum.com] has quit [Ping timeout: 480 seconds] 17:57 #dri-devel: < marex> mripard: btw may I ask you to be a bit more patient with Jagan ? The samsung patches are in like v14 now, it would be really good to finally get those merges, and I think there is like one single outstanding issue now 17:58 #dri-devel: < mripard> a single outstanding issue we've been discussing since v9 iirc 17:58 #dri-devel: < mripard> and that he always ignored 17:59 #dri-devel: < mripard> and he managed to ignore it in both submissions he did today 17:59 #dri-devel: < marex> mripard: I am aware of that, but I'm afraid stomping on it with NAK isn't going to achieve the right outcome 17:59 #dri-devel: < mripard> so no, sorry, I believe I've already been more than patient on this one 18:00 #dri-devel: < marex> mripard: lemme have a look at that discussion again 18:00 #dri-devel: < mripard> I mean, it was a NAK unless you change it 18:00 #dri-devel: < mripard> if he changes it, then I'll happily reconsider it, and I already provided what he needs to change it and make me happy 18:01 #dri-devel: < mripard> at this point, I'm not sure what I can bring to the discussion, hence why I wrote that. 18:04 -!- hansg [~hans@2001:1c00:c32:7800:5bfa:a036:83f0:f9ec] has joined #dri-devel 18:06 #dri-devel: < marex> mripard: is my understanding correct, that all he has to do is s@devm_@drmm_@ ? 18:07 #dri-devel: < marex> hm, no ... 18:08 -!- molinari [~molinari@176-151-233-216.abo.bbox.fr] has quit [Ping timeout: 480 seconds] 18:08 #dri-devel: < sergi> anholt_: the bot is trying uprev_piglit_in_mesa every night but some jobs doesn't produce artifacts when uprev piglit. In a case like that, what the bot does is to create an issue in the target project (aka mesa) https://gitlab.freedesktop.org/mesa/mesa/-/issues/8360 18:08 #d3d9: < adavy> DavidHeidelberg[m]: how would that work ? 18:08 #d3d9: < adavy> How do you check the trace is ok 18:08 #d3d9: < DavidHeidelberg[m]> we use checksum generated from the image 18:09 -!- KnM [~mdnavare@c-73-157-143-109.hsd1.or.comcast.net] has joined #intel-gfx 18:09 #dri-devel: < mripard> marex: he needs to move the call to drm_of_find_panel and bridge to bind 18:09 #dri-devel: < mripard> first 18:09 #d3d9: < DavidHeidelberg[m]> adavy: of course, the trace has to be reproducible without change, even in one pixel color by 1 18:10 #dri-devel: < mripard> then create the drmm helper you were mentioning 18:10 #dri-devel: < mripard> and this whole dance to work around the fact that you don't have a pointer to the drm device is moot 18:10 #d3d9: < DavidHeidelberg[m]> If you see radv-raven-traces, I'm using the wine with dxvk and checking against the checksum 18:11 #dri-devel: < anholt_> sergi: so you just keep opening and closing MRs, and then what's supposed to happen? Are you investigating those issues? 18:12 #d3d9: < adavy> you check against the very same hw I assume 18:12 #dri-devel: < marex> mripard: to ... bind ? 18:12 #dri-devel: < marex> mripard: or to samsung DSIM driver probe ? 18:12 #dri-devel: < marex> mripard: which bind ? 18:12 #dri-devel: < marex> struct mipi_dsi_host_ops has no ->bind callback 18:12 #d3d9: < adavy> How do you handle if there is a small driver change that affects visual in a negligible way ? 18:13 #dri-devel: < marex> I do see of_drm_find_panel() used in driver probe callbacks however 18:13 #dri-devel: < mripard> to exynos_dsi_bind 18:14 #d3d9: < DavidHeidelberg[m]> You check in html UI differences and then say its ok or its broken 18:14 #dri-devel: < sergi> anholt_: MRs with the tag "testonly" are from my user while testing the tool. The bot is running it every night and should create MRs without this tag. In case the bot cannot complete the process, it creates an issue trying to explain. At this point, who will integrate an uprev proposal would come from one that knows more than I. About investigating the cause of the issue, you are right, I can do that. At least start, and request help in case I 18:14 #dri-devel: < sergi> don't know more. 18:15 #dri-devel: < marex> but wait, that's outside of this driver, the DSIM bridge driver can also be used by i.MX 'lcdif' and 'mxsfb' drivers 18:15 #dri-devel: < marex> er, please ignore that 18:15 -!- manuel1985 [~manuel198@62.99.131.178] has quit [Ping timeout: 480 seconds] 18:17 #dri-devel: < marex> mripard: actually, no, dont ignore that ... should the drm_of_find_panel also go into samsung_dsim_register_host ? 18:17 #dri-devel: < marex> mripard: as far as I understand it now, drivers/gpu/drm/exynos/exynos_drm_dsi.c is the Exynos glue code , samsung_dsim_register_host and co is the i.MX glue code 18:18 #dri-devel: < mripard> marex: you can't use drm_of_find_panel or its bridge variant 18:18 #dri-devel: < mripard> I mean, you can, DSIM is the proof of that, it's just broken. 18:19 #dri-devel: < mripard> and you can end up in probe deadlocks depending on the situation 18:19 #dri-devel: < marex> mripard: let's just focus on the first part , i.e. the "move ... to bind", first 18:19 #dri-devel: < marex> mripard: and then second which exact function to use 18:19 #dri-devel: < sergi> anholt_: would be nice if we (together) can think in a workflow. I have an idea about the thinks that could be made automatically with the "post" uprev section https://gitlab.freedesktop.org/gfx-ci/ci-uprev/-/issues/27 But there are things, like what you mention about investigate the issue, that requires a human 18:20 #dri-devel: < mareko> radeonsi can't fully switch to scoped barriers due to differences between LLVM and ACO 18:20 #dri-devel: < marex> mripard: so do I understand it right that the ... drm_whatever_panel ... should be called from both exynos_dsi_bind() and samsung_dsim_register_host() ? 18:21 #dri-devel: < marex> basically before mipi_dsi_host_register() ? 18:21 -!- daz [~root@2a04:9dc0:0:133::a01e] has joined #wayland 18:21 #dri-devel: < cmarcelo> mareko: what information is missing in the scoped barrier? 18:21 #dri-devel: < mripard> samsung_dsim_register_host isn't in the current source tree, so I don't know for that one 18:21 #dri-devel: < mripard> but it must be called at bind time 18:22 #dri-devel: < marex> mripard: so do I understand it right that the ... drm_whatever_panel ... should be called from both exynos_dsi_bind() and samsung_dsi_register_host() ? 18:22 #dri-devel: < marex> errr ... 18:22 #freedesktop: < Consolatis> I am just some random dude but if gitlab.freedesktop.org would have required any kind of "social" oauth login I would have never signed up in the first place. I still think that you can't combat spam without alienating users. So instead the incentives for spamming should be reduced as much as possible. (no public access to non-whitelisted repos, new issue limit for new users, no ability to post links in issues for new users) 18:23 #dri-devel: < mripard> drm_whatever_panel must be called at bind time 18:23 #dri-devel: < marex> mripard: try generic_dsim_register_host 18:24 #dri-devel: < marex> ... which is called at ... ugh 18:24 #dri-devel: < mripard> not in 6.2 either 18:24 #dri-devel: < marex> mripard: its in patch v13 14/18 18:24 #dri-devel: < mripard> but how the driver is organized is pretty much orthogonal. If that function is called directly by the driver bind, then fine 18:24 #dri-devel: < anholt_> sergi: my workflow recommendation would be: drop [TESTONLY] from the MR title once your testing and conclusion-writing process is done, but keep the MR open. Then people can see it. Report the problems in the MR instead of an issue, because that text is only really useful in the context of the MR. Also, s/TESTONLY/WIP/ would make more sense. 18:24 #dri-devel: < mripard> if it isn't, then it's pbroken 18:24 -!- Aison [~Ivo@2a02:168:200f:100::1:1] has quit [Remote host closed the connection] 18:24 -!- d42 [~root@2a04:9dc0:0:133::a01e] has quit [Ping timeout: 480 seconds] 18:25 #dri-devel: < marex> mripard: its actually called from platform driver ->probe callback 18:25 #dri-devel: < marex> mripard: that should be OK, no ? 18:25 -!- MajorBiscuit [~MajorBisc@c-001-027-039.client.tudelft.eduvpn.nl] has quit [Ping timeout: 480 seconds] 18:25 -!- MajorBiscuit [~MajorBisc@c-001-027-039.client.tudelft.eduvpn.nl] has quit [Ping timeout: 480 seconds] 18:25 -!- MajorBiscuit [~MajorBisc@c-001-027-039.client.tudelft.eduvpn.nl] has quit [Ping timeout: 480 seconds] 18:25 -!- MajorBiscuit [~MajorBisc@c-001-027-039.client.tudelft.eduvpn.nl] has quit [Ping timeout: 480 seconds] 18:25 -!- MajorBiscuit [~MajorBisc@c-001-027-039.client.tudelft.eduvpn.nl] has quit [Ping timeout: 480 seconds] 18:25 -!- MajorBiscuit [~MajorBisc@c-001-027-039.client.tudelft.eduvpn.nl] has quit [Ping timeout: 480 seconds] 18:26 #dri-devel: < mripard> https://patchwork.kernel.org/project/dri-devel/patch/20230227113925.875425-5-jagan@amarulasolutions.com/ 18:26 #dri-devel: < mripard> that one is definitely not ok. 18:26 #dri-devel: < marex> that much I understand, yes 18:27 #dri-devel: < marex> mripard: should it go into https://patchwork.kernel.org/project/dri-devel/patch/20230227113925.875425-13-jagan@amarulasolutions.com/ just before +return mipi_dsi_host_register(&dsim->dsi_host); ? 18:27 #dri-devel: < mripard> and in 14, samsung_dsim_host_attach isn't bind either 18:28 -!- swatish2 [~swatish2@134.134.139.80] has quit [Ping timeout: 480 seconds] 18:29 #dri-devel: < sergi> anholt_: The "testonly" tag is from local executions on my machine or from a pre-merge pipeline in ci-uprev (this project uses also marge and tries the uprevs). But those MRs with this tag are only experiments, not made to be used later. The gfx-ci-bot has an scheduled pipeline each midnight (in UTC terms) and creates what we may call "production" MRs for uprev. Those are real candidates. 18:29 #dri-devel: < mripard> mipi_dsi_host_register is called at probe time, which isn't bind? 18:29 #wayland: < kennylevinsen> DodoGTA: all object IDs are dynamic, obtained when the object is created or bound 18:29 #dri-devel: < marex> mripard: yes, that's called at probe time 18:30 #dri-devel: < mripard> then no? 18:30 #dri-devel: < marex> mripard: so ... which bind ? 18:30 #dri-devel: < marex> mripard: just, point me to the structure name I am looking for 18:30 #dri-devel: < sergi> anholt_: But yes, in this case, I'm seeing that I was producing uprev candidates since enter in production. And after that, this piglit uprev starts having trouble with some jobs and their artifacts creation. 18:31 #dri-devel: < mripard> marex: it's late, it's a driver I don't know, patches I wasn't cc'd for 18:31 #dri-devel: < mripard> I'm not going to dig into a 15 patches series 18:31 #dri-devel: < sergi> anholt_: I'll review why those jobs are failing and see if there is something I can do, or ask for help 18:31 #dri-devel: < marex> mripard: mipi_dsi_host_ops doesnt have a bind callback 18:31 -!- Aison [~Ivo@2a02:168:200f:100::1:1] has joined #radeon 18:31 #dri-devel: < mripard> my review is, since 5 versions, follow the doc: https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges 18:31 #dri-devel: < anholt_> ok, so I guess I've only ever seen your personal test MRs, not the production ones? Have any production ones been generated yet? 18:32 #dri-devel: < marex> mripard: and each driver which uses of_drm_find_panel does so in driver probe 18:32 #radeon: < Aison> _ds_, agd5f: https://pastebin.com/0NDYiwpC 18:32 #radeon: < Aison> segfault 18:32 #dri-devel: < mripard> well, each driver is broken then 18:32 #dri-devel: < mripard> vc4 isn't though. 18:32 -!- mowcat [~mowcat@2a00:23c5:d190:1901:f22f:74ff:fe77:1e1c] has quit [Remote host closed the connection] 18:33 #dri-devel: < mripard> I'm really not sure how it's an argument though. 18:33 #dri-devel: < marex> mripard: but vc4 isnt a bridge, is it ? 18:33 #dri-devel: < marex> mripard: I am not arguing, I am trying to understand what to change to move the discussion forward 18:34 -!- Supersaiyan_IV [~QAM@ua-85-228-153-205.bbcust.telenor.se] has joined #intel-gfx 18:34 -!- Supersaiyan_IV [~QAM@ua-85-228-153-205.bbcust.telenor.se] has joined #radeon 18:35 #dri-devel: < marex> mripard: oh component_ops ->bind ? 18:36 #dri-devel: < mripard> vc4_dsi is a bridge in drm-misc-next 18:36 #dri-devel: < mripard> https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c 18:36 #dri-devel: < marex> mripard: https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805 so this bind is the one you're talking about ? 18:39 #dri-devel: < mripard> yes 18:39 #dri-devel: < marex> mripard: OK, understood, and thanks for the example, that helps a great deal 18:40 #dri-devel: < marex> mripard: but there is one more problem here, the imx side doesn't use the component stuff 18:40 -!- alyssa [~alyssa@rosenzweig.io] has joined #dri-devel 18:40 #dri-devel: < alyssa> 23:53 The other thing is that the pass right now assumes your back-end uses it for everything. It takes bytes rather than a (bit_size, num_components) pair as the input to the callback. It doesn't distinguish between, say, a u8vec4 and a uint if they're both 4B aligned. That's fine for all the HW I'm familiar with, though. 18:40 #dri-devel: < alyssa> 23:53 Maybe not the most friendly for API translation but fine for HW. 18:40 #dri-devel: < alyssa> It does lead to some silly things, though 18:40 #dri-devel: < mripard> marex: then I think you can get away with it by calling it in probe 18:40 #dri-devel: < sergi> anholt_: I think it didn't have the opportunity to create a single one in production 18:41 #dri-devel: < alyssa> Like an aligned u16vec4 turning into a u32vec2 and a pile of unpacks 18:41 #dri-devel: < marex> mripard: ahhhhhh 18:41 #dri-devel: < mripard> so I guess you'd need two callbacks, one supposed to be called in probe, the other in bind 18:41 #dri-devel: < marex> mripard: THANK YOU 18:41 #dri-devel: < mripard> exynos would call the probe callback in its probe, and the bind in its bind 18:41 #dri-devel: < marex> mripard: I think I understand it now 18:41 #dri-devel: < alyssa> This shouldn't be a problem for AGX since we can coalesce away all the packs 18:41 #dri-devel: < alyssa> *unpacks 18:41 #dri-devel: < mripard> while imx would call both the probe and bind callbacks in its probe 18:41 #dri-devel: < mripard> that would probably work 18:41 #dri-devel: < alyssa> IDK if the Bifrost compiler is that smart. 18:41 #dri-devel: < alyssa> gfxstrand: ^ sorry that got split up across threads 18:42 #dri-devel: < mripard> but I'd still test those odd cases in the documentation on imx 18:42 -!- cousin_luigi [~luigi@freeshell.de] has joined #intel-gfx 18:42 #intel-gfx: < cousin_luigi> Hello 18:42 #intel-gfx: < cousin_luigi> Does tbzatek ever come here? 18:42 -!- lynxeye [~lynxeye@2a02:560:58a5:c300:20e1:7881:a58b:630d] has quit [Quit: Leaving.] 18:42 -!- lynxeye [~lynxeye@2a02:560:58a5:c300:20e1:7881:a58b:630d] has quit [Quit: Leaving.] 18:42 #dri-devel: < marex> mripard: I'll try to summarize that and provide feedback ... and, I cannot test on exynos, so all my tests happen on imx 18:42 #dri-devel: < marex> mripard: that part should be covered at least 18:43 #wayland: < zzag> DodoGTA: https://invent.kde.org/plasma/kwin/-/merge_requests/3711 might fix the issue, otherwise let's continue the discussion in https://webchat.kde.org/#/room/#kwin:kde.org 18:43 #dri-devel: < sergi> anholt_: I see the source of the problem. I hope I'll have a solution soon 18:48 #dri-devel: < marex> mripard: and the function name would them be still of_drm_find_panel() or some drmm_ variant ? 18:49 #dri-devel: < mripard> it doesn't really matter, it'd be better to use a drmm function straight away, but if you don't want a managed version that's fine too 18:50 #dri-devel: < mripard> a device managed version is not really an option though 18:50 #dri-devel: < marex> so unbind has to do clean up? 18:52 -!- jmdaemon [~jmdaemon@0002d6bd.user.oftc.net] has joined #wayland 18:54 #radeon: < _ds_> Aison, maybe test -rc8 then bisect (limiting it to drivers/gpu/drm)? 18:55 #dri-devel: < marex> mripard: OK, mail is out, let's see what happens 18:55 #dri-devel: < marex> mripard: thanks for clarifying this to me 18:55 -!- dviola [~diego@0002b89a.user.oftc.net] has quit [Quit: WeeChat 3.7.1] 18:55 -!- dviola [~diego@0002b89a.user.oftc.net] has quit [Quit: WeeChat 3.7.1] 18:55 -!- dviola [~diego@0002b89a.user.oftc.net] has quit [Quit: WeeChat 3.7.1] 18:55 -!- dviola [~diego@0002b89a.user.oftc.net] has quit [Quit: WeeChat 3.7.1] 18:55 -!- dviola [~diego@0002b89a.user.oftc.net] has quit [Quit: WeeChat 3.7.1] 18:55 #dri-devel: < mripard> you're welcom 19:01 -!- arsenm [~Adium@82.197.100.55] has joined #radeon 19:02 #wayland: < emersion> reminder: libwayland alpha tomorrow 19:07 -!- Szadek [~Szadek@185.209.196.179] has quit [Ping timeout: 480 seconds] 19:08 -!- Szadek [~Szadek@194.36.25.10] has joined #wayland 19:09 #dri-devel: < gfxstrand> alyssa: If there's genuine value in doing so, we could make the callback take an actual (bit_size, num_components) pair. It's just a bit of a pain to maintain that in the case where we end up splitting something into multiple loads. 19:09 #dri-devel: < gfxstrand> I guess we could always reduce everything to the smallest bit-size you've ever requested or something dumb like that. 19:10 #dri-devel: < gfxstrand> And so far, I've primarily worked with two flavors of hardware that need this sort of splitting: 19:10 #dri-devel: < gfxstrand> 1) AMD/Intel where there's a scalar unaligned load/store that needs to be used for align < 4 and a 4B-aligned vector load/store which you use for everything else. 19:11 #dri-devel: < gfxstrand> 2) NVIDIA where load/store operate on any power-of-two size from 1B to 16B and it requires the same alignment as the amount of data being accessed. 19:11 #dri-devel: < gfxstrand> In both cases, they're happy to eat a bit of pack/unpack. 19:15 -!- phasta [~phasta@82.207.245.25] has quit [Remote host closed the connection] 19:15 -!- phasta [~phasta@82.207.245.25] has quit [Remote host closed the connection] 19:15 -!- phasta [~phasta@82.207.245.25] has quit [Remote host closed the connection] 19:19 -!- ngcortes [~ngcortes@134.134.139.71] has joined #dri-devel 19:19 -!- ngcortes [~ngcortes@134.134.139.71] has joined #intel-gfx 19:19 -!- ngcortes [~ngcortes@134.134.139.71] has joined #intel-3d 19:20 #freedreno: < abhinav__> lumag sboyd Can you please review https://patchwork.freedesktop.org/patch/524044/ ? Wanted to include this for the next -fixes 19:21 #freedesktop: < alanc> is the banner supposed to appear on pushes by existing users to our own repos? I just got it on a push over ssh to git@gitlab.freedesktop.org:alanc/xserver.git 19:23 -!- mmu_man [~revol@188410969.box.freepro.com] has quit [Ping timeout: 480 seconds] 19:24 #freedesktop: < daniels> alanc: if you dismiss it in the web UI, it should also no longer appear for SSH 19:25 #freedesktop: < alanc> I had dismissed it in the web ui before that 19:30 -!- manuel1985 [~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf] has joined #wayland 19:31 -!- KnM [~mdnavare@c-73-157-143-109.hsd1.or.comcast.net] has quit [Ping timeout: 480 seconds] 19:37 -!- nchery [~nchery@134.134.137.82] has joined #intel-gfx 19:37 -!- nchery [~nchery@134.134.137.82] has joined #intel-3d 19:37 -!- nchery [~nchery@134.134.137.82] has joined #dri-devel 19:39 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #dri-devel 19:39 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #wayland 19:39 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #radeon 19:43 -!- mmu_man [~revol@82-65-227-82.subs.proxad.net] has joined #nouveau 19:45 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has quit [Quit: Leaving] 19:45 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has quit [Quit: Leaving] 19:45 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has quit [Quit: Leaving] 19:45 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has quit [Quit: Leaving] 19:45 -!- tzimmermann [~tzimmerma@2001:9e8:21ee:ad00:d317:31e3:e2e3:8cca] has quit [Quit: Leaving] 19:47 -!- ybogdano is now known as Guest6101 19:47 -!- ybogdano is now known as Guest6101 19:47 -!- ybogdano is now known as Guest6101 19:47 -!- ybogdano is now known as Guest6101 19:47 -!- ybogdano is now known as Guest6101 19:47 -!- ybogdano [~ybogdano@134.134.139.85] has joined #freedesktop 19:47 -!- ybogdano [~ybogdano@134.134.139.85] has joined #intel-gfx 19:47 -!- ybogdano [~ybogdano@134.134.139.85] has joined #intel-3d 19:47 -!- ybogdano [~ybogdano@134.134.139.85] has joined #dri-devel 19:47 -!- ybogdano [~ybogdano@134.134.139.85] has joined #wayland 19:48 -!- Prax [~oftc-webi@43-4-133-N4.customer.vsm.sh] has joined #dri-devel 19:48 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Ping timeout: 480 seconds] 19:48 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Ping timeout: 480 seconds] 19:48 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Ping timeout: 480 seconds] 19:48 -!- Prax [~oftc-webi@43-4-133-N4.customer.vsm.sh] has quit [Remote host closed the connection] 19:49 -!- slisovsk [~slisovsk@134.134.139.70] has quit [Ping timeout: 480 seconds] 19:49 #d3d9: < adavy> Ok, I guess one or two light ones could be useful 19:54 -!- Remco_ is now known as Remco 19:54 -!- Pr4x [~oftc-webi@43-4-133-N4.customer.vsm.sh] has joined #dri-devel 20:01 -!- Pr4x [~oftc-webi@43-4-133-N4.customer.vsm.sh] has quit [Remote host closed the connection] 20:04 #d3d9: < DavidHeidelberg[m]> Sure 20:05 -!- mvchtz [~ubuntu@2a02:587:620d:729c:ba27:ebff:fe04:cdd6] has quit [Ping timeout: 480 seconds] 20:05 -!- mvchtz [~ubuntu@2a02:587:620d:729c:ba27:ebff:fe04:cdd6] has quit [Ping timeout: 480 seconds] 20:07 -!- Zopolis4 [uid504804@id-504804.ilkley.irccloud.com] has joined #dri-devel 20:08 -!- vkareh [~vkareh@00026f70.user.oftc.net] has quit [Quit: Leaving] 20:08 #dri-devel: < alyssa> gfxstrand: Yeah that's valid 20:08 #dri-devel: < alyssa> AGX/Mali are class #2 generally speaking 20:09 -!- hogander [~jhogande@134.191.220.81] has quit [] 20:09 -!- Tom^ [~tom@h-158-174-67-168.A159.priv.bahnhof.se] has joined #nouveau 20:10 -!- _ds_ [~d.s@00014df3.user.oftc.net] has quit [Remote host closed the connection] 20:11 -!- _ds_ [~d.s@00014df3.user.oftc.net] has joined #radeon 20:12 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #dri-devel 20:12 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #wayland 20:12 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #radeon 20:13 -!- KnM [~mdnavare@c-73-157-143-109.hsd1.or.comcast.net] has joined #intel-gfx 20:15 -!- mvchtz [~ubuntu@2a02:587:620e:14a:ba27:ebff:fe04:cdd6] has joined #radeon 20:15 -!- mvchtz [~ubuntu@2a02:587:620e:14a:ba27:ebff:fe04:cdd6] has joined #intel-gfx 20:15 #intel-gfx: < nchery> how does the WC mapping work for gfx allocations? is userspace expected to use a memory barrier when it's done writing? or does the kernel handle this somehow? 20:16 #intel-3d: < dcbaker> If I want to bitshift in C, with the lhs as a numeric literal, and I want to ensure it's 64 bit, you do that with `1ll << x` or `1ull << x` (depending on unsigned vs signed), right? 20:16 -!- gouchi [~gouchi@78.196.21.187] has joined #dri-devel 20:16 #dri-devel: < alyssa> Well, Mali is #2 20:17 #dri-devel: < alyssa> AGX is 1B/2B/4B elements requiring natural alignment and you can do up to 4 of them at a time 20:17 #dri-devel: < gfxstrand> Ok, that's a bit weird 20:17 #dri-devel: < alyssa> meh, it's basically spicy #2 20:17 #dri-devel: < jenatali> DXIL looks like AGX too 20:18 #dri-devel: < alyssa> jenatali: obviously, everyone knows that Direct3D was designed for Apple GPUs right? 20:18 #dri-devel: < jenatali> Obviously 20:18 #dri-devel: < alyssa> or was it Apple GPUs designed for Direct3D? 20:18 #dri-devel: < alyssa> i forget 20:18 #dri-devel: * alyssa adjusts tinfoil hat 20:18 #dri-devel: < gfxstrand> I mean, if someone wants to figure out what the loops should look like operating on bits/comps instead of raw bytes, I'm not opposed. 20:21 #dri-devel: < alyssa> I don't think there's any benefit for AGX 20:22 #dri-devel: < alyssa> but I haven't thought about this in too much detail 20:22 -!- mvchtz is now known as Guest6105 20:22 -!- mvchtz is now known as Guest6105 20:22 -!- mvchtz [~ubuntu@2a02:587:620e:14a:ba27:ebff:fe04:cdd6] has joined #radeon 20:22 -!- mvchtz [~ubuntu@2a02:587:620e:14a:ba27:ebff:fe04:cdd6] has joined #intel-gfx 20:22 #dri-devel: < gfxstrand> I doubt there's much benefit to DXIL, either, given that it's going to get converted right back into one of the two modes by the client driver anyway. 20:22 -!- junaid_ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #dri-devel 20:22 -!- junaid_ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #wayland 20:22 -!- junaid_ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #radeon 20:23 #dri-devel: < alyssa> Provided that we can coalesce the unpacks, I imagine i32vec2+unpack is equal perf to the original i16vec4 20:23 -!- Guest6105 [~ubuntu@2a02:587:620e:14a:ba27:ebff:fe04:cdd6] has quit [Read error: No route to host] 20:23 -!- Guest6105 [~ubuntu@2a02:587:620e:14a:ba27:ebff:fe04:cdd6] has quit [Read error: No route to host] 20:23 #dri-devel: < gfxstrand> probalby 20:23 #dri-devel: < alyssa> (Just carrying the restriction that it needs 4 byte alignment instead of 2) 20:23 #dri-devel: < gfxstrand> But that's for RA to sort out 20:23 #dri-devel: < gfxstrand> And RA is magic 20:23 #dri-devel: < alyssa> Oh... and it requires its destination to be 2-reg aligned instead of unaligned 20:24 -!- gouchi [~gouchi@0002b959.user.oftc.net] has quit [Quit: Quitte] 20:24 -!- jernej [~jernej@0002b859.user.oftc.net] has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net] 20:24 -!- jernej [~jernej@0002b859.user.oftc.net] has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net] 20:24 -!- jernej [~jernej@0002b859.user.oftc.net] has joined #dri-devel 20:24 -!- jernej [~jernej@0002b859.user.oftc.net] has joined #lima 20:24 #dri-devel: < alyssa> which (once RA is competent) does not affect register pressure but might result in extra moves/shuffles due to unnecessary live range splitting 20:24 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Ping timeout: 480 seconds] 20:24 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Ping timeout: 480 seconds] 20:24 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Ping timeout: 480 seconds] 20:24 -!- junaid__ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #dri-devel 20:24 -!- junaid__ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #wayland 20:24 -!- junaid__ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #radeon 20:25 #dri-devel: < alyssa> basically where I'm at is, I think the splitting logic is fine in the cases we really do need to split 20:25 #dri-devel: < alyssa> but it's a bit of a blunt hammer that ends up splitting for instrucitons that didn't actually need the split 20:26 #dri-devel: < alyssa> if I could filter on (num components, bitsize) but do splitting in terms of bytes, that'd probably be good enough 99% of the time 20:27 -!- cousin_luigi [~luigi@freeshell.de] has left #intel-gfx [] 20:27 #dri-devel: < alyssa> as it is, I don't think I can distinguish i64 scalar loads (which need to be split) from i32vec2 and i16vec4 loads (which don't) 20:28 #dri-devel: < alyssa> (for the RA friendliness, possibly I could promote i32vec2 loads to i16vec4 at isel time. but that'll probably be worse overall because you really did want the alignment when the result is used as a 32-bit scalar) 20:28 #dri-devel: < gfxstrand> I think today's project is parallel copy lowering. 20:28 #dri-devel: < alyssa> Seems legit 20:28 #dri-devel: < alyssa> I copypasted cwabbott's code, twice 20:28 #dri-devel: < alyssa> Works like a charm 20:29 #dri-devel: < alyssa> Even added unit tests 20:29 #intel-3d: < zmike> sounds right 20:29 #dri-devel: < gfxstrand> I should probably look at how ACO does it and use a better data structure so Daniel doesn't chide me for chosing confusing algorithms. 😅 20:29 -!- Deluxe [~Deluxe@212.4.150.151] has quit [Remote host closed the connection] 20:29 #dri-devel: < alyssa> who cares what data structure you use 20:29 #dri-devel: < alyssa> this isn't exactly a hotspot :p 20:29 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #dri-devel 20:29 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #wayland 20:29 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #radeon 20:30 -!- dcz_ [~dcz@78.48.144.251] has quit [Ping timeout: 480 seconds] 20:30 #dri-devel: < alyssa> Vec 20:30 -!- flto [~root@modemcable125.110-19-135.mc.videotron.ca] has quit [Remote host closed the connection] 20:30 -!- flto [~root@modemcable125.110-19-135.mc.videotron.ca] has quit [Remote host closed the connection] 20:30 -!- junaid___ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #dri-devel 20:30 -!- junaid___ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #wayland 20:30 -!- junaid___ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #radeon 20:30 #dri-devel: < gfxstrand> lol 20:31 #dri-devel: < gfxstrand> More that the NIR impl aparently confuses people. 20:31 -!- junaid__1 [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #dri-devel 20:31 -!- junaid__1 [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #wayland 20:31 -!- junaid__1 [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #radeon 20:33 #intel-3d: < zmike> fjdegroo: I think we're getting to the good perf stuff now 20:33 -!- flto [~root@modemcable125.110-19-135.mc.videotron.ca] has joined #freedreno 20:33 -!- flto [~root@modemcable125.110-19-135.mc.videotron.ca] has joined #dri-devel 20:34 #intel-3d: < fjdegroo> zmike: I think so. On my DG2 it's clearly the blorp/draw ping-ponging 20:34 #intel-3d: < zmike> strange that you're still seeing any blorp activity 20:34 #intel-3d: < fjdegroo> zmike: I don't think I have access to ICL. I could try on TGL though. 20:34 #intel-3d: < zmike> are you seeing copies in blorp or ? 20:35 #intel-3d: < zmike> all I have is some hiz/ccs stuff there 20:36 #intel-3d: < fjdegroo> zmike: maybe you could capture intel_measure data for what you're seeing. I'd suggest "INTEL_MEASURE=draw" and "INTEL_MEASURE=batch" 20:36 #intel-3d: < zmike> sure 20:37 -!- KnM [~mdnavare@c-73-157-143-109.hsd1.or.comcast.net] has quit [Ping timeout: 480 seconds] 20:37 -!- Aison [~Ivo@2a02:168:200f:100::1:1] has quit [Remote host closed the connection] 20:37 #intel-3d: < zmike> fjdegroo: separately or draw,batch ? 20:37 -!- rv1sr [~rv1sr@0002da44.user.oftc.net] has quit [] 20:37 #intel-gfx: < airlied> nchery: wc maps aren't cached anywhere, though you do in theory have to flush the wc combiner, but doing any pci access will do that 20:37 #intel-3d: < fjdegroo> sorry, separate 20:38 #intel-3d: < zmike> https://gitlab.freedesktop.org/mesa/mesa/uploads/d103387f98b4d926f577ad149cc84632/zink-draw.txt https://gitlab.freedesktop.org/mesa/mesa/uploads/87a1382eaeb8cc77ade14b98c63c506b/zink-batch.txt 20:38 -!- flto [~root@modemcable125.110-19-135.mc.videotron.ca] has quit [Remote host closed the connection] 20:38 -!- flto [~root@modemcable125.110-19-135.mc.videotron.ca] has quit [Remote host closed the connection] 20:39 #intel-3d: < zmike> with --loop=5 to do a few non-setup frames 20:40 -!- flto [~root@modemcable125.110-19-135.mc.videotron.ca] has joined #freedreno 20:40 -!- flto [~root@modemcable125.110-19-135.mc.videotron.ca] has joined #dri-devel 20:40 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has quit [Read error: Connection reset by peer] 20:40 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has quit [Read error: Connection reset by peer] 20:40 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has joined #etnaviv 20:40 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has joined #dri-devel 20:41 #intel-3d: < fjdegroo> zmike: thanks mike. Can you collect similar with iris? both batch and then draw? 20:41 #intel-3d: < zmike> ah yeah, sure 20:42 #wayland: < emersion> would anyone have a few minutes to ack/review this? https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/291 20:42 #dri-devel: < mareko> cmarcelo: no information as far as I know 20:42 #intel-3d: < fjdegroo> zmike: I can confirm that you are NOT seeing the blorp activity that I'm seeing. It might be HW difference. 20:42 #intel-3d: < zmike> https://gitlab.freedesktop.org/mesa/mesa/uploads/dda71eb75d1ec78a505fe4fa7d25f307/iris-batch.txt https://gitlab.freedesktop.org/mesa/mesa/uploads/748eb7ed8057556a3510580494720cb6/iris-draw.txt 20:43 #intel-3d: < zmike> ICL 💪 20:43 #wayland: < wlb> wayland/main: Sebastian Wick * protocol: do not change pending x and y when attaching a buffer https://gitlab.freedesktop.org/wayland/wayland/commit/2aec8f59e9c0 protocol/wayland.xml 20:43 #wayland: < wlb> wayland Merge request !295 merged \o/ (protocol: do not change pending x and y when attaching a buffer https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/295) 20:43 #freedreno: < Hazematman> I created a "WIP MR" for my KGSL backend changes. I'm hoping to get some feedback on the changes as there are some things I'm not 100% sure about. Specifically around what I will call the "platform" level code for EGL and Gallium. My changes feel a bit more like a hack than proper changes 20:43 #freedreno: < Hazematman> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21570#935ba26c64fdeeed91b568a9ea34a6190ef3ca61 20:43 #intel-3d: < zmike> fjdegroo: try zmike/test, I added the perf patch on top 20:43 #intel-3d: < zmike> maybe I pushed the wrong ref before somehow (promise I won't touch that one anymore) 20:44 -!- mowcat [~mowcat@2a00:23c5:d190:1901:f22f:74ff:fe77:1e1c] has joined #radeon 20:45 -!- YuGiOhJCJ [~YuGiOhJCJ@00021b1f.user.oftc.net] has quit [Quit: YuGiOhJCJ] 20:46 #wayland: < wlb> wayland Issue #322 closed \o/ (Inconsistent implementation of wl_data_offer.source_actions https://gitlab.freedesktop.org/wayland/wayland/-/issues/322) 20:46 #wayland: < wlb> wayland/main: Vlad Zahorodnii * protocol: reorder wl_data_offer.source_actions and wl_data_device.enter https://gitlab.freedesktop.org/wayland/wayland/commit/3815803633a6 protocol/wayland.xml 20:46 #wayland: < wlb> wayland Merge request !270 merged \o/ (protocol: reorder wl_data_offer.source_actions and wl_data_device.enter https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/270) 20:46 #wayland: < bl4ckb0ne> why are some aliases missing? 20:46 #intel-3d: < fjdegroo> zmike: maybe. I'll try zmike/test 20:47 #intel-3d: < zmike> I'm hoping it's the same and it's a hw difference 20:48 #intel-3d: < fjdegroo> zmike: I see a lot of variation in your batch durations. I'm guessing you aren't fixing the GPU frequency. You will be able to generate more consistent GPU timing if you fix the GPU frequency. 20:48 #intel-3d: < fjdegroo> zmike: that's more of an FYI 20:48 #intel-3d: < zmike> with gamemode you mean? 20:48 #intel-3d: < zmike> I wasn't bothering since the perf gap is currently so large 20:49 #intel-3d: < fjdegroo> zmike: I have never used gamemode (although I probably should give it a try) I use my script. Let me find it 20:50 #dri-devel: < cmarcelo> mareko: can you elaborate on the differences between ACO and LLVM you were talking about earlier? 20:51 #wayland: < emersion> old code taken from Xorg 20:51 #intel-3d: < fjdegroo> zmike: this is how I fix my GT frequency. https://gitlab.freedesktop.org/fjdegroo/mesa/-/snippets/7591 20:52 #intel-3d: < zmike> oh cool 20:52 #intel-3d: * zmike saves a script 20:52 #intel-3d: < zmike> thanks 20:52 #intel-3d: < fjdegroo> zmike: It works on recent HW but no idea about ICL. Maybe give it a try and then montior gpu freq using intel_gpu_top 20:52 #wayland: < wlb> wayland Merge request !63 closed (build: Fix strndup detection on MinGW) 20:53 #dri-devel: < mareko> cmarcelo: nir_var_shader_out in the scoped barrier is handled differently between ACO and LLVM 20:53 #intel-3d: < fjdegroo> frequency arg is in MHz. 20:53 #intel-3d: < fjdegroo> you should be able to set 800 MHz at least on ICL 20:54 #wayland: < wlb> wayland/main: Mikhail Gusarov * protocol: Clarify meaning of input region for cursors, DnD icons https://gitlab.freedesktop.org/wayland/wayland/commit/6cdeae1becef protocol/wayland.xml 20:54 #wayland: < wlb> wayland Merge request !281 merged \o/ (protocol: Clarify meaning of input region for cursors, DnD icons https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/281) 20:55 #freedreno: < robclark> Hazematman: jfyi, fairly recently meson freedreno-virtio and freedreno-kgsl options where collapsed into a single freedreno-kmds list (since you are adding kgsl for gallium and I am adding virtio for tu).. so that probably changes slightly your meson.build changes 20:55 #freedreno: * robclark will look over the rest more closely a bit later 20:55 #intel-3d: < zmike> hmmm it doesn't seem to be locked to that freq, at least according to intel_gpu_top 20:56 #intel-3d: < fjdegroo> zmike: try running a gpu heavy workload and check the frequency. 20:56 #intel-3d: < zmike> I'm checking while running a trace 20:56 #intel-3d: < fjdegroo> zmike: if the GPU goes to sleep (RC6) then it can throw your reported frequency off 20:57 #intel-3d: < fjdegroo> zmike: it also might be that the script doesn't work well on ICL. Never tried that 20:58 #wayland: < bl4ckb0ne> i mean from the specs, the patch doesnt add all of them 20:59 #wayland: < bl4ckb0ne> is it only the DnD stuff? 20:59 #freedreno: < Hazematman> robclark: That's good to know, that just made me realize I rebased my changes against my local copy of mesa main and not the remote copy. 21:00 #dri-devel: < DemiMarie> Would Mesa be better off without using LLVM for AMD and just generating AMD shader machine code directly? 21:00 #intel-3d: < zmike> think I have to set /sys/class/drm/card1/gt_boost_freq_mhz too 21:00 #intel-3d: < Kayden> I've never had to do that 21:00 #wayland: < emersion> only the cursors in the built-in theme 21:00 #dri-devel: < gfxstrand> Oh, you mean like RADV does with ACO? 21:00 #intel-3d: < zmike> shrug 21:00 #intel-3d: < zmike> I set it and it stopped going over 800 21:00 #intel-3d: < Kayden> the script there is referring to card0, is yours card1? 21:00 #intel-3d: < zmike> yes 21:00 #wayland: < emersion> the list above the new entries contains the old names 21:00 #dri-devel: < gfxstrand> DemiMarie: ^^ 21:00 #intel-3d: < zmike> I changed the script locally 21:00 #intel-3d: < Kayden> okay cool :) 21:01 #dri-devel: < gfxstrand> DemiMarie: I think that depends on who you ask. 😅 21:01 #dri-devel: < DemiMarie> gfxstrand: no idea what RADV or ACO mean 21:01 #dri-devel: < gfxstrand> RADV is the Vulkan driver for AMD HW that's in Mesa. 21:01 #wayland: < emersion> thanks! 21:01 #intel-3d: < zmike> scattered today but not that scattered 21:01 #dri-devel: < gfxstrand> ACO is the non-LLVM back-end compiler it uses. 21:01 -!- molinari [~molinari@176-151-233-216.abo.bbox.fr] has joined #wayland 21:02 #wayland: < wlb> wayland/main: Simon Ser * shm: fix segfault when accessing destroyed pool resource https://gitlab.freedesktop.org/wayland/wayland/commit/ab526f8d7c80 src/wayland-shm.c 21:02 #wayland: < wlb> wayland Merge request !268 merged \o/ (shm: fix segfault when accessing destroyed pool resource https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/268) 21:03 #dri-devel: < gfxstrand> DemiMarie: Short version is that all the big pieces are in place such that radeonsi could switch over. Some work would have to be done to get ACO working with GL. It's got some Vulkan or RADV assumptions in it today and radeonsi has a bunch of LLVM assuptions. 21:03 #dri-devel: < gfxstrand> Nothing that isn't fixable. 21:03 -!- pa- [~pa@host-87-1-12-182.retail.telecomitalia.it] has quit [Read error: Connection timed out] 21:03 #dri-devel: < gfxstrand> But various parties have differing interests so there hasn't been a concerted effort to make it happen. 21:03 #dri-devel: < DemiMarie> Will Zink eventually be the only OpenGL driver? 21:04 -!- pa [~pa@host-87-1-12-182.retail.telecomitalia.it] has joined #dri-devel 21:04 #dri-devel: < jenatali> Doubtful 21:04 #dri-devel: < DemiMarie> Is this for performance reasons? 21:04 #dri-devel: < pixelcluster> gfxstrand: iirc aren't there some people working towards ACO with GL? 21:05 #dri-devel: < pixelcluster> I think I remember seeing MRs hinting that 21:05 #dri-devel: < gfxstrand> pixelcluster: There's been various people who've chipped away a bit. 21:05 #dri-devel: < pixelcluster> I see 21:05 #dri-devel: < zmike> I'm using it with GL every day! 21:06 #dri-devel: < DemiMarie> What advantages does ACO have over LLVM? 21:07 #dri-devel: < ccr> I have no idea, but I'd bet one of the biggest advantage is that it's not LLVM :P 21:07 #intel-3d: < fjdegroo> zmike: yup, still seeing implicit copies between draws with zmike/test. Seems that your fix/workaround isn't being applied to DG2. 21:07 #dri-devel: < gfxstrand> hehe 21:07 #intel-3d: < zmike> huh. 21:07 #dri-devel: < gfxstrand> Probably the biggest advantage is that it's blazingly fast 21:07 #intel-3d: < zmike> I'd guess then that the copies are happening from something else? 21:07 #intel-3d: < fjdegroo> zmike: I can try it on TGL, but not sure if that will be similar to DG2 of ICL. 21:07 #dri-devel: < gfxstrand> While LLVM is a bit of a pig. 21:07 #intel-3d: < zmike> you're using --loop, yes? 21:07 #dri-devel: < gfxstrand> I think the AMD folks have gotten their LLVM compile times manageable but it's still LLVM. 21:07 #intel-3d: < fjdegroo> yes 21:08 #intel-3d: < zmike> hm 21:08 #intel-3d: < zmike> very strange then 21:08 #intel-3d: < zmike> I guess you're getting copies from somewhere else 21:08 #dri-devel: < DemiMarie> Also LLVM aborts on OOM. 21:08 #intel-3d: < fjdegroo> zmike: were you able to force the GPU frequency on your ICL with my script while under load? 21:08 #dri-devel: < DemiMarie> Are LLVM’s optimizations useful here? 21:09 #intel-3d: < zmike> I think it might only affect the maximum? or at least I see " / " and with the script I can clamp val2 to 800 21:09 #intel-3d: < zmike> but val1 is still varying wildly 21:09 #dri-devel: < alyssa> gfxstrand: hey that's mean 21:09 #dri-devel: < alyssa> to pigs 21:09 -!- alyssa [~alyssa@rosenzweig.io] has quit [Quit: leaving] 21:10 #dri-devel: < gfxstrand> alatiera: :P 21:10 #dri-devel: < gfxstrand> alyssa, rather 21:11 -!- Supersaiyan_IV [~QAM@ua-85-228-153-205.bbcust.telenor.se] has quit [Ping timeout: 480 seconds] 21:11 -!- Supersaiyan_IV [~QAM@ua-85-228-153-205.bbcust.telenor.se] has quit [Ping timeout: 480 seconds] 21:11 #intel-3d: < fjdegroo> zmike: bummer. Are you able to fully load the gpu? are you seeing "0% RC6" in intel_gpu_top? 21:11 -!- fab [~fab@bellet.info] has quit [Quit: fab] 21:12 #intel-3d: < zmike> hm no, looks like the traces don't load it fully 21:12 #intel-3d: < zmike> with supertuxkart it's up to 85-90% 21:13 -!- bvivekan_ [~bvivekan@122.166.101.63] has joined #intel-gfx 21:13 #intel-3d: < zmike> or maybe I flipped those numbers 21:13 -!- junaid__ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 21:13 -!- junaid__ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 21:13 -!- junaid__ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 21:13 -!- junaid__1 [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 21:13 -!- junaid__1 [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 21:13 -!- junaid__1 [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 21:13 -!- junaid___ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 21:13 -!- junaid___ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 21:13 -!- junaid___ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 21:13 -!- junaid_ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 21:13 -!- junaid_ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 21:13 -!- junaid_ [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 21:13 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 21:13 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 21:13 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 21:13 #intel-3d: < fjdegroo> 85% RC6 or 15% RC6? you want the second 21:14 #intel-3d: < zmike> no, I was mistaken and the process had silently exited 21:14 #intel-3d: < zmike> I'm at 1-2% 21:15 -!- bvivekan [~bvivekan@122.166.101.63] has quit [Ping timeout: 480 seconds] 21:17 -!- ricotz [~ricotz@155.133.217.97] has quit [Quit: Leaving] 21:21 #freedreno: < Hazematman> I re based against the "real mesa main" this time :P the MR now incorporates the `freedreno-kmds` list changes 21:23 #freedesktop: < kj> Could @imgtec.com be added in as well? Just had someone try fork mesa and didn't have permission 21:23 -!- lemonzest [~lemonzest@cpc86080-nott19-2-0-cust160.12-2.cable.virginm.net] has quit [Quit: WeeChat 3.6] 21:23 -!- lemonzest [~lemonzest@cpc86080-nott19-2-0-cust160.12-2.cable.virginm.net] has quit [Quit: WeeChat 3.6] 21:27 #intel-3d: < fjdegroo> zmike: so, at 1-2% RC6, and while running the GPU frequency setting script, are you able to see 800MHz consistent GPU freq? 21:28 #intel-3d: < zmike> fjdegroo: I see two numbers: like 671/ 799 MHz 21:28 #intel-3d: < zmike> or do I ignore the first one? 21:28 #intel-3d: < zmike> the second number is consistently about 800 21:28 #intel-3d: < fjdegroo> zmike: the second one is your frequency. I forget what the first one is. 21:28 #intel-3d: < zmike> ah ok 21:28 #intel-3d: < zmike> then yeah, working perfectly 21:28 -!- hansg [~hans@2001:1c00:c32:7800:5bfa:a036:83f0:f9ec] has quit [Quit: Leaving] 21:29 #intel-3d: < mattst88> one is a rolling average, IIRC 21:29 #intel-3d: < fjdegroo> zmike: cool. the problem is traces tend to have trouble to feed enough work to the GPU to keep it out of RC6. I bet if you ran the live load you would have better luck 21:30 #intel-3d: < mattst88> I never have had good luck reading frequencies accurately from either intel_gpu_top or via cat'ing files in sysfs. 21:30 #intel-3d: < mattst88> what has worked well for me is capturing the GPU clock in perfetto 21:30 #intel-3d: < fjdegroo> zmike: what you want to figure out is if the perf delta is caused by lower GPU freq or something else 21:30 #intel-3d: < zmike> gotcha 21:30 #intel-3d: < fjdegroo> mattst88: yeah, that works too 21:31 -!- manuel1985 [~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf] has quit [Ping timeout: 480 seconds] 21:31 #intel-3d: < fjdegroo> zmike: maybe you just need perfetto traces of both iris and zink. You may want to use live workload. 21:31 #intel-3d: < zmike> if I'm seeing 0% RC6 that's what I want, yes? 21:31 #intel-3d: < mattst88> FWIW, https://dpaste.com/EAV82UX8W is the perfetto.sh script I use on ChromeOS; probably need to remove some chromeos-specific data sources for it to work on Linux 21:32 #freedesktop: < kj> The account in question is JarredHDavies. Could he get internal user permissions? He's trying to create an MR in relation to the powervr driver in mesa 21:32 #intel-3d: < zmike> hm will check this out... 21:32 #intel-3d: < zmike> fjdegroo: I'm seeing consistent 800MHz for both zink and iris 21:33 #intel-3d: < fjdegroo> zmike: 0% RC6 at 800MHz is good. you're GPU frequency is fixed (while under load) 21:34 #intel-3d: < zmike> the results are the same: still about a 25% perf diff 21:36 #freedreno: < robclark> thx 21:37 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has quit [Quit: Ex-Chat] 21:37 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has quit [Quit: Ex-Chat] 21:37 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has quit [Quit: Ex-Chat] 21:48 #freedesktop: < bentiss> kj: I made JarredHDavies internal, he can now fork/create projects 21:48 -!- KnM [~mdnavare@c-73-157-143-109.hsd1.or.comcast.net] has joined #intel-gfx 21:48 -!- jkrzyszt [~jkrzyszt@134.191.221.86] has joined #intel-gfx 21:48 -!- jkrzyszt [~jkrzyszt@134.191.221.86] has joined #dri-devel 21:49 #intel-3d: < fjdegroo> zmike: switching to TGL got rid of the extra copies. 21:49 #intel-3d: < fjdegroo> for me 21:49 #intel-3d: < zmike> \o/ 21:49 #freedesktop: < kj> Thanks. I'll let him know 21:49 #intel-3d: < fjdegroo> zmike: probably an issue related to discrete card 21:49 #freedesktop: < bentiss> and added imgtech.com in the allowlist. Future users will be able to fork without asking permission 21:50 #intel-3d: < zmike> weird one 21:51 #dri-devel: < agd5f> DemiMarie, LLVM has a lot of useful stuff for compute (e.g., support for functions, and eventually debugger support with GDB) that may be useful for gfx eventually. 21:53 #freedesktop: < kj> imgtech.com would make more sense but all the emails are @imgtec.com for some reason. Sorry for bothering you again 21:55 #dri-devel: < gfxstrand> We should start seeing functions pop up in NIR compilers before too long, I think. 21:56 #freedesktop: < bentiss> well, if the email is without the 'h', then we can keep it that way :) 21:57 #dri-devel: < jenatali> I'd love to see debug data support come through 21:58 #dri-devel: < jenatali> Not looking forward to writing the PDB writer for DXIL but I am looking forward to source-stepping 21:58 #dri-devel: < gfxstrand> Yeah, I need to go see where that's at. 21:58 #dri-devel: < gfxstrand> I know there were some NIR patches. I gave some comments. Some things happened. IDK where they're at now. 21:59 #intel-3d: < fjdegroo> zmike: On my tigerlake (tgl) zink it running at 50% perf as iris. Looking deeper... 21:59 -!- ice9 [~ice9@0001f41b.user.oftc.net] has quit [Ping timeout: 480 seconds] 21:59 -!- ice9 [~ice9@0001f41b.user.oftc.net] has quit [Ping timeout: 480 seconds] 22:00 #intel-3d: < zmike> whoa that's really low 22:07 -!- Guest3910 [~elmindred@87.96.175.11] has quit [Ping timeout: 480 seconds] 22:07 -!- Guest3910 [~elmindred@87.96.175.11] has quit [Ping timeout: 480 seconds] 22:11 -!- Duke`` [~plop@2a01cb0007977800eb0dededc85d5cc6.ipv6.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 22:11 -!- Duke`` [~plop@2a01cb0007977800eb0dededc85d5cc6.ipv6.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 22:12 #intel-3d: < fjdegroo> zmike: stalls looks good. iris matches zink stall count roughly. Not yet sure why it's so slow yet... 22:13 #intel-3d: < zmike> at least I'm not doing anything too obviously wrong 22:15 #intel-3d: < fjdegroo> zmike: nope. looks like you're doing everything right so far. 22:15 #intel-3d: < fjdegroo> checking out perfetto now 22:15 #intel-3d: < zmike> gonna screenshot this and frame it on my wall 22:18 -!- Leopold___ [~quassel@4JHAAACF1.tor-irc.dnsbl.oftc.net] has joined #intel-3d 22:18 -!- Leopold___ [~quassel@4JHAAACF1.tor-irc.dnsbl.oftc.net] has joined #freedesktop 22:18 -!- Leopold___ [~quassel@4JHAAACF1.tor-irc.dnsbl.oftc.net] has joined #intel-gfx 22:18 -!- Leopold___ [~quassel@4JHAAACF1.tor-irc.dnsbl.oftc.net] has joined #lima 22:18 -!- Leopold___ [~quassel@4JHAAACF1.tor-irc.dnsbl.oftc.net] has joined #dri-devel 22:18 -!- Leopold___ [~quassel@4JHAAACF1.tor-irc.dnsbl.oftc.net] has joined #radeon 22:18 -!- Leopold___ [~quassel@4JHAAACF1.tor-irc.dnsbl.oftc.net] has joined #nouveau 22:18 -!- Leopold___ [~quassel@4JHAAACF1.tor-irc.dnsbl.oftc.net] has joined #etnaviv 22:18 -!- Leopold___ [~quassel@4JHAAACF1.tor-irc.dnsbl.oftc.net] has joined #wayland 22:22 #freedreno: < jessica_24> hey lumag, Marijn[m]: finally got panel with DSC 1.2 working on the sm8350: https://photos.app.goo.gl/fFH5mVrm1kBY5ZNk7 :) there's an issue in the panel driver reset though so working on debugging that and cleaning up the patches 22:23 #dri-devel: < karolherbst> yeah, let's ditch llvm, it's a constant pain 🙃 22:23 -!- heat [~heat@0002b861.user.oftc.net] has joined #dri-devel 22:23 -!- heat [~heat@0002b861.user.oftc.net] has joined #intel-gfx 22:23 -!- heat [~heat@0002b861.user.oftc.net] has joined #intel-3d 22:23 #freedreno: < konradybcio> woah congratz! jessica_24 22:24 #dri-devel: < karolherbst> (still wants to see aco hooked up in radeonsi) 22:24 #dri-devel: < karolherbst> gfxstrand: it essentially works, I might have one or two patches, but nothing huge 22:24 #dri-devel: < karolherbst> there are two bigger issues I'm seeing with proper function support in nir 22:25 #dri-devel: < karolherbst> 1. a proper function inlining pass 22:25 #dri-devel: < karolherbst> 2. backends 22:25 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 22:25 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 22:25 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 22:25 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 22:25 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 22:25 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 22:25 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 22:25 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 22:25 -!- Leopold_ [~quassel@4JHAAACFA.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 22:25 #freedreno: < abhinav__> we found few issues with DSC programming too, will post fixes in the same series 22:33 #dri-devel: < agd5f> modulo dealing with the DWARF standards body, we have GDB support in branches today, at least for compute, more or less on par with what you'd get from a CPU 22:33 #dri-devel: < danvet> airlied, you need to fix your dim setup so no copypasting is needed, dim gets the subject right :-P 22:38 #dri-devel: < gfxstrand> karolherbst: Those are a couple of load-bearing issues you've got there. 😅 22:38 #dri-devel: < airlied> danvet: oh I don't use dim to send the pull requests 22:38 #dri-devel: < airlied> because I don't use mutt 22:38 #dri-devel: < karolherbst> gfxstrand: yeah.. guess why I didn't started to look into it yet :) 22:38 #dri-devel: < danvet> airlied, ask jani 22:38 #dri-devel: < airlied> I only use dim to produce the pull request txt 22:38 #dri-devel: < danvet> yeah I know :-) 22:39 #dri-devel: < airlied> but I don't want to use dim to send me PR either 22:39 #dri-devel: < karolherbst> though I still plan to do the work for llvmpipe + radeonsi and see where it goes 22:39 #dri-devel: < karolherbst> but other drivers will probably have to do the work themselves 22:39 #dri-devel: < airlied> I write it up in gmail, but yes the subject line is my defeat 22:40 #dri-devel: < danvet> iirc what jani has done is do a little script to drop the output of dim into a draft or something suitable for whatever thing you're using 22:40 #dri-devel: < danvet> but that was for notmuch 22:40 -!- bgs [~bgs@212-85-160-171.dynamic.telemach.net] has quit [Remote host closed the connection] 22:40 #dri-devel: < danvet> and set that script as DIM_MUA 22:41 #dri-devel: < airlied> I could have it email me I suppose and then edit the email before sending it on 22:41 #dri-devel: < danvet> fwd: [GIT PULL] drm-next would be hilarious 22:42 #dri-devel: < airlied> yeah I'd still find a way to screw it up 22:44 #dri-devel: < jani> danvet: I actually upstreamed a notmuch-emacs-mua script to mimic mutt cli interface for composing. it generates the email, but I can edit and hit send at my leisure after that 22:45 #dri-devel: * airlied doubts there's a neat gmail integration here :-P 22:45 #dri-devel: < jani> airlied: I'm sure it's just a SMOP 22:45 #dri-devel: * airlied can't even spawn firefox since it's a remote machine 22:46 #dri-devel: < airlied> jani: indeed! 22:47 #dri-devel: < jani> it could be a merge request on gitlab where some action generates and sends the pull request mail 22:48 #dri-devel: < airlied> yes that would be a later dream :-P 22:49 -!- apinheiro [~infapi00@78.0.27.77.dynamic.reverse-mundo-r.com] has quit [Quit: Leaving] 22:49 #dri-devel: < jani> the sad part is, this is all just git, with a lossy medium in between 22:49 #freedreno: < lumag> jessica_24, sounds great! 22:50 #intel-3d: < fjdegroo> zmike: :) 22:50 #intel-3d: < fjdegroo> zmike: I've got the data but something isn't making sense to me yet. I gotta switch off this for a couple days but will try to get back to it this week. sorry. 22:50 #dri-devel: < jani> and pr-tracker-bot is a hack that monitors and cross-references a mailing list and a git repository 22:50 #intel-3d: < zmike> fjdegroo: sure thing, no rush 22:50 #intel-3d: < fjdegroo> thx 22:50 #intel-3d: < zmike> ty 22:51 -!- hardening [~quassel@arennes-655-1-19-105.w109-218.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 22:52 -!- heat [~heat@0002b861.user.oftc.net] has quit [Remote host closed the connection] 22:52 -!- heat [~heat@0002b861.user.oftc.net] has quit [Remote host closed the connection] 22:52 -!- heat [~heat@0002b861.user.oftc.net] has quit [Remote host closed the connection] 22:52 -!- heat [~heat@0002b861.user.oftc.net] has joined #intel-3d 22:52 -!- heat [~heat@0002b861.user.oftc.net] has joined #intel-gfx 22:52 -!- heat [~heat@0002b861.user.oftc.net] has joined #dri-devel 22:55 -!- Moprius [~Thunderbi@177.51.38.31] has joined #radeon 22:55 -!- Moprius [~Thunderbi@177.51.38.31] has joined #wayland 22:58 #dri-devel: < jenatali> Question for a Vulkan expert: Is it valid to dynamically index between samplers that are bound to a pipeline as immutable samplers? 22:58 -!- drod [~ldm@ip-95-220-105-14.bb.netbynet.ru] has quit [Remote host closed the connection] 22:59 #dri-devel: < gfxstrand> yes 22:59 #dri-devel: < gfxstrand> They're just samplers 22:59 #dri-devel: < gfxstrand> From a shader POV, they're not different. 22:59 #dri-devel: < gfxstrand> Unless you're doing YCbCr 22:59 #dri-devel: < jenatali> Alright 22:59 #dri-devel: < jenatali> D3D puts a restriction there FWIW 23:01 #freedreno: < Marijn[m]> Looking good, didn't expect any different. Hope the fixes effect the other SoCs in one go too 23:02 #dri-devel: < gfxstrand> I guess it's possible Vulkan has some but I'm unaware of them. 23:03 -!- Moprius [~Thunderbi@0002e253.user.oftc.net] has quit [Quit: bye] 23:03 -!- Moprius [~Thunderbi@0002e253.user.oftc.net] has quit [Quit: bye] 23:04 #dri-devel: < gfxstrand> They do get weird around descriptor buffers. 23:04 #dri-devel: < gfxstrand> IDK why we allowed the two to interact, TBH. We should have just killed off immutable samplers except for YCbCr. 23:04 #dri-devel: < jenatali> Yeah 23:04 #dri-devel: * jenatali shrugs 23:05 #dri-devel: < Wallbraker> Arg I can't remember the name for the thing, but like everything in a execution wave needs to select the same sampler. 23:05 #dri-devel: < jenatali> Dynamically uniform 23:05 #dri-devel: < Wallbraker> That's that the! 23:06 #dri-devel: < Wallbraker> the name* 23:07 #dri-devel: < jenatali> Alright well then I guess I'll have to not map them to static samplers when supporting descriptor_indexing 23:07 #dri-devel: < jenatali> Oh well 23:07 -!- mvchtz [~ubuntu@2a02:587:620e:14a:ba27:ebff:fe04:cdd6] has quit [Ping timeout: 480 seconds] 23:07 -!- mvchtz [~ubuntu@2a02:587:620e:14a:ba27:ebff:fe04:cdd6] has quit [Ping timeout: 480 seconds] 23:07 -!- mvchtz [~ubuntu@athedsl-149776.home.otenet.gr] has joined #radeon 23:07 -!- mvchtz [~ubuntu@athedsl-149776.home.otenet.gr] has joined #intel-gfx 23:08 -!- nchery [~nchery@134.134.137.82] has quit [Ping timeout: 480 seconds] 23:08 -!- nchery [~nchery@134.134.137.82] has quit [Ping timeout: 480 seconds] 23:08 -!- nchery [~nchery@134.134.137.82] has quit [Ping timeout: 480 seconds] 23:09 #dri-devel: < Wallbraker> I would check the spec, as my memories is very hazy here. 23:12 #dri-devel: < Wallbraker> https://www.khronos.org/opengl/wiki/Sampler_(GLSL)#Non-uniform_flow_control 23:12 -!- rasterman [~rasterman@80.7.141.101] has quit [Quit: Gettin' stinky!] 23:12 -!- rasterman [~rasterman@80.7.141.101] has quit [Quit: Gettin' stinky!] 23:13 -!- caveman [~caveman@0002bdf0.user.oftc.net] has quit [Remote host closed the connection] 23:13 -!- heyman94 [~heyman@4G4AACYX9.tor-irc.dnsbl.oftc.net] has quit [Remote host closed the connection] 23:13 -!- caveman [~caveman@0002bdf0.user.oftc.net] has joined #wayland 23:13 -!- heyman94 [~heyman@7YZAACOUU.tor-irc.dnsbl.oftc.net] has joined #nouveau 23:17 -!- tuxracer68 [~mundi@51.154.102.17] has joined #nouveau 23:17 #freedreno: < robclark> heh, forcing gmem size to 32x16 makes gpu really slow 23:21 -!- tuxracer [~mundi@51.154.102.17] has quit [Ping timeout: 480 seconds] 23:29 -!- nchery [~nchery@134.134.139.84] has joined #intel-gfx 23:29 -!- nchery [~nchery@134.134.139.84] has joined #intel-3d 23:29 -!- nchery [~nchery@134.134.139.84] has joined #dri-devel 23:31 -!- tuxracer [~mundi@51.154.102.17] has joined #nouveau 23:35 -!- tuxracer68 [~mundi@51.154.102.17] has quit [Ping timeout: 480 seconds] 23:35 -!- feto_bastardo4 [~fetobasta@ec2-3-20-180-149.us-east-2.compute.amazonaws.com] has quit [] 23:37 -!- Zopolis4 [uid504804@id-504804.ilkley.irccloud.com] has quit [] 23:40 -!- smiles [~smiles@2409:8a00:db0:5800:c76:ca8d:a1a:d77b] has joined #dri-devel 23:41 -!- jkrzyszt [~jkrzyszt@134.191.221.86] has quit [Ping timeout: 480 seconds] 23:41 -!- jkrzyszt [~jkrzyszt@134.191.221.86] has quit [Ping timeout: 480 seconds] 23:42 -!- aravind [~aravind@134.134.139.84] has joined #intel-gfx 23:42 -!- aravind [~aravind@134.134.139.84] has joined #dri-devel 23:47 -!- alyssa [~alyssa@rosenzweig.io] has joined #dri-devel 23:47 #dri-devel: < alyssa> karolherbst: proper inlining is the biggie 23:48 #dri-devel: < alyssa> backend support will be churn but whatever, I'm not scared of it 23:48 #dri-devel: < alyssa> I would type the patches if there was a point (right now there's not, absent proper inlining) 23:53 -!- tuxracer68 [~mundi@51.154.102.17] has joined #nouveau 23:53 -!- tuxracer [~mundi@51.154.102.17] has quit [Ping timeout: 480 seconds] 23:56 #dri-devel: < anholt_> tarceri_: removing grafting is looking fairly good with your matrix reassociator. 23:56 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 23:56 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 23:56 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 23:56 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 23:56 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 23:57 -!- tarceri_ [~tarceri@121.122.220.111.sta.wbroadband.net.au] has quit [] 23:57 -!- tarceri_ [~tarceri@121.122.220.111.sta.wbroadband.net.au] has quit [] 23:57 -!- tarceri_ [~tarceri@121.122.220.111.sta.wbroadband.net.au] has quit [] 23:57 -!- tarceri_ [~tarceri@121.122.220.111.sta.wbroadband.net.au] has quit [] 23:58 -!- tarceri [~tarceri@121.122.220.111.sta.wbroadband.net.au] has joined #dri-devel 23:58 -!- tarceri [~tarceri@121.122.220.111.sta.wbroadband.net.au] has joined #intel-3d 23:58 -!- tarceri [~tarceri@121.122.220.111.sta.wbroadband.net.au] has joined #intel-gfx 23:58 -!- tarceri [~tarceri@121.122.220.111.sta.wbroadband.net.au] has joined #radeon 23:59 #dri-devel: < tarceri> Yeah its mostly there, but I was still digging around in the shader-db results before I put it on the back burner --- Log closed Tue Feb 28 00:00:53 2023