--- Log opened Tue Feb 28 00:00:53 2023 --- Day changed Tue Feb 28 2023 00:00 #dri-devel: < tarceri> maybe its better than when I last looked, things are always moving forward 00:01 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 00:01 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 00:01 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 00:01 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 00:01 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 00:01 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 00:01 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 00:03 #dri-devel: < anholt_> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21578 has some stats for freedreno. 00:04 #dri-devel: < anholt_> note that that MR doesn't include opt_algebraic gutting or copy prop removal. 00:05 #dri-devel: < tarceri> I think one of the things was I needed to handle things other than just mat4 or vec4 00:05 #dri-devel: < tarceri> I think there was a least 1 regression in shaderdb from that 00:06 #dri-devel: < anholt_> I've got a couple listed there. 00:06 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has quit [Quit: dodo] 00:06 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has quit [Quit: dodo] 00:07 #dri-devel: < anholt_> oh, something I was thinking about as we make progress on this: since nir_opt_algrebraic is good at matching the biggest pattern, I think some of the variants you have dealing with 1.0s being optimized away should end up being unnecessary once we have GLSL optimization deleted. 00:08 -!- paulk-bis [~paulk@vpn-0-22.aquilenet.fr] has quit [Ping timeout: 480 seconds] 00:08 -!- paulk-bis [~paulk@vpn-0-22.aquilenet.fr] has quit [Ping timeout: 480 seconds] 00:08 #dri-devel: < tarceri> I hope so because I think there were more corner cases 00:09 -!- bvivekan [~bvivekan@122.166.101.63] has joined #intel-gfx 00:12 #dri-devel: < tarceri> Although I think nir might have been getting to them first also 00:13 #dri-devel: < tarceri> *nir opts 00:13 -!- bvivekan_ [~bvivekan@122.166.101.63] has quit [Ping timeout: 480 seconds] 00:19 #dri-devel: < alyssa> ~irregular reminder that alu is cheap and memory is not~ 00:23 -!- bvivekan_ [~bvivekan@122.166.101.63] has joined #intel-gfx 00:23 #dri-devel: < alyssa> (so I'm good with small shaderdb alu count regressions if they mean shorter compile time, etc) 00:25 #dri-devel: < tarceri> It's really a massive chain of todos with these things. You try to remove one pass and you need to remove another handful, fix ten year old bugs, and speedup NIR passes :P 00:26 #dri-devel: < alyssa> Lol 00:26 #dri-devel: < alyssa> I want a graph of "line count of src/compiler/glsl/ over time" 00:26 #dri-devel: < anholt_> finding that glsl ir opt code I wrote 13 years ago is still load-bearing is a little distressing. 00:26 #dri-devel: < alyssa> scaled appropriately and captioned "not stonks" 00:27 #dri-devel: < zmike> ideally zoomed in until it has become pixelated 00:27 #dri-devel: < alyssa> 100% 00:28 -!- paulk-bis [~paulk@vpn-0-22.aquilenet.fr] has joined #dri-devel 00:28 -!- paulk-bis [~paulk@vpn-0-22.aquilenet.fr] has joined #wayland 00:28 #dri-devel: < tarceri> lol 00:28 -!- bvivekan [~bvivekan@122.166.101.63] has quit [Ping timeout: 480 seconds] 00:30 #dri-devel: < anholt_> alyssa: btw, did the midgard change you suggested (I think) in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21476 00:30 #dri-devel: < tarceri> I'm not sure if it will ever get there but ideally GLSL IR would get to a point were its just a small layer between ast and nir. Being able to to the gl compile calls in NIR would be great rather than having to wait until link time. 00:31 -!- nchery [~nchery@134.134.139.84] has quit [Ping timeout: 480 seconds] 00:31 -!- nchery [~nchery@134.134.139.84] has quit [Ping timeout: 480 seconds] 00:31 -!- nchery [~nchery@134.134.139.84] has quit [Ping timeout: 480 seconds] 00:33 #dri-devel: < alyssa> anholt_: italove was working on that AFAIK, not planning to work on it myself unless italove gets stuck 00:35 #dri-devel: < alyssa> anholt_: Oh, I see you added patches yourself 00:37 #dri-devel: < alyssa> r-b'd 00:44 -!- bodicceaII [~bodiccea@2a01:e34:ed64:e6c0:4ecc:6aff:feb3:9232] has quit [Remote host closed the connection] 00:44 -!- bodicceaII [~bodiccea@2a01:e34:ed64:e6c0:4ecc:6aff:feb3:9232] has joined #wayland 00:44 -!- aravind [~aravind@134.134.139.84] has quit [Ping timeout: 480 seconds] 00:44 -!- aravind [~aravind@134.134.139.84] has quit [Ping timeout: 480 seconds] 00:51 -!- CYBERDEViL [~CYBERDEVi@193.138.218.218] has joined #nouveau 00:56 -!- nchery [~nchery@134.134.139.84] has joined #intel-gfx 00:56 -!- nchery [~nchery@134.134.139.84] has joined #intel-3d 00:56 -!- nchery [~nchery@134.134.139.84] has joined #dri-devel 00:56 -!- mowcat [~mowcat@2a00:23c5:d190:1901:f22f:74ff:fe77:1e1c] has quit [Remote host closed the connection] 00:57 #intel-gfx: < nchery> arlied: got it. thanks! 00:59 -!- alyssa [~alyssa@rosenzweig.io] has quit [Quit: leaving] 01:03 -!- stuart [~jssummer@192.55.54.52] has quit [] 01:03 -!- stuart [~jssummer@192.55.54.52] has quit [] 01:07 #radeon: < cheako> Just to keep ppl updated, I don't think gfxrc is creating a fence and then when calling wait just uses 0. I've opened an issue(but here again communicating with others is hard), I don't know if I'll do much more with this. 01:26 -!- nchery [~nchery@134.134.139.84] has quit [Remote host closed the connection] 01:26 -!- nchery [~nchery@134.134.139.84] has quit [Remote host closed the connection] 01:26 -!- nchery [~nchery@134.134.139.84] has quit [Remote host closed the connection] 01:26 -!- columbarius [~columbari@i5387A686.versanet.de] has joined #dri-devel 01:26 -!- columbarius [~columbari@i5387A686.versanet.de] has joined #wayland 01:26 -!- nchery [~nchery@134.134.139.84] has joined #intel-gfx 01:26 -!- nchery [~nchery@134.134.139.84] has joined #intel-3d 01:26 -!- nchery [~nchery@134.134.139.84] has joined #dri-devel 01:28 -!- co1umbarius [~columbari@i5387A694.versanet.de] has quit [Ping timeout: 480 seconds] 01:28 -!- co1umbarius [~columbari@i5387A694.versanet.de] has quit [Ping timeout: 480 seconds] 01:34 -!- tuxracer [~mundi@51.154.102.17] has joined #nouveau 01:35 -!- yuq825 [~yuq@180.152.11.27] has joined #lima 01:35 -!- yuq825 [~yuq@180.152.11.27] has joined #dri-devel 01:38 -!- tuxracer68 [~mundi@51.154.102.17] has quit [Ping timeout: 480 seconds] 01:40 -!- molinari [~molinari@176-151-233-216.abo.bbox.fr] has quit [Ping timeout: 480 seconds] 01:41 -!- tuxracer68 [~mundi@51.154.102.17] has joined #nouveau 01:43 #wayland: < wlb> weston Merge request !1180 opened by Leandro Ribeiro (leandrohrb) xwayland: Handle shell hint for client to choose dimensions https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1180 01:44 -!- tuxracer [~mundi@51.154.102.17] has quit [Ping timeout: 480 seconds] 01:53 -!- Company [~Company@ip1f1264d8.dynamic.kabel-deutschland.de] has quit [Quit: Leaving] 01:53 -!- Company [~Company@ip1f1264d8.dynamic.kabel-deutschland.de] has quit [Quit: Leaving] 01:57 -!- TMM [hp@amanda.tmm.cx] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 01:57 -!- TMM [hp@amanda.tmm.cx] has joined #dri-devel 02:13 -!- CYBERDEViL [~CYBERDEVi@193.138.218.218] has quit [] 02:20 #dri-devel: < kode54> where should I report an issue with the xe kmd? the mailing list? 02:21 -!- andyrtr_ [~andyrtr@ip5b426757.dynamic.kabel-deutschland.de] has joined #intel-3d 02:21 -!- andyrtr_ [~andyrtr@ip5b426757.dynamic.kabel-deutschland.de] has joined #intel-gfx 02:21 -!- andyrtr_ [~andyrtr@ip5b426757.dynamic.kabel-deutschland.de] has joined #nouveau 02:21 -!- andyrtr_ [~andyrtr@ip5b426757.dynamic.kabel-deutschland.de] has joined #radeon 02:21 -!- andyrtr_ [~andyrtr@ip5b426757.dynamic.kabel-deutschland.de] has joined #wayland 02:21 -!- andyrtr [~andyrtr@91.66.103.87] has quit [Ping timeout: 480 seconds] 02:21 -!- andyrtr [~andyrtr@91.66.103.87] has quit [Ping timeout: 480 seconds] 02:21 -!- andyrtr [~andyrtr@91.66.103.87] has quit [Ping timeout: 480 seconds] 02:21 -!- andyrtr [~andyrtr@91.66.103.87] has quit [Ping timeout: 480 seconds] 02:21 -!- andyrtr [~andyrtr@91.66.103.87] has quit [Ping timeout: 480 seconds] 02:21 -!- andyrtr_ is now known as andyrtr 02:21 -!- andyrtr_ is now known as andyrtr 02:21 -!- andyrtr_ is now known as andyrtr 02:21 -!- andyrtr_ is now known as andyrtr 02:21 -!- andyrtr_ is now known as andyrtr 02:28 -!- nchery [~nchery@134.134.139.84] has quit [Ping timeout: 480 seconds] 02:28 -!- nchery [~nchery@134.134.139.84] has quit [Ping timeout: 480 seconds] 02:28 -!- nchery [~nchery@134.134.139.84] has quit [Ping timeout: 480 seconds] 02:30 #dri-devel: < airlied> kode54: there is also the xe gitlab repo, I think it has issues enabled, or just the ml 02:31 -!- gtristan [~tristan@223.38.36.112] has joined #freedesktop 02:38 -!- fjdegroo [~fjdegroo@134.134.139.71] has quit [Read error: Connection reset by peer] 02:38 #dri-devel: < kode54> I'll check there 02:41 #dri-devel: < kode54> oh, already reported: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/210 02:42 -!- sparky4 [~sparky4@hutcheson-192.resnet.latech.edu] has quit [Remote host closed the connection] 02:43 #dri-devel: < kode54> oh damn 02:43 #dri-devel: < kode54> I didn't notice that repo was ahead of cgit.freedesktop.org/drm/drm-xe 02:59 -!- gtristan [~tristan@223.38.36.112] has quit [Remote host closed the connection] 03:00 -!- gtristan [~tristan@223.38.36.112] has joined #freedesktop 03:01 -!- kinkinkijkin [~kinkinkij@162.246.53.59] has quit [Quit: Leaving] 03:12 -!- gtristan [~tristan@223.38.36.112] has quit [Ping timeout: 480 seconds] 03:26 -!- aravind [~aravind@192.55.54.51] has joined #intel-gfx 03:26 -!- aravind [~aravind@192.55.54.51] has joined #dri-devel 03:38 -!- windleaves [~windleave@124.89.8.225] has joined #dri-devel 03:40 -!- julio7359 [~julio7359@75.172.139.251] has joined #wayland 03:41 -!- Mary6 [~Mary@2a01:4f9:6b:22d0::3] has quit [] 03:41 -!- Mary6 [~Mary@2a01:4f9:6b:22d0::3] has joined #nouveau 03:49 -!- nerdopolis [~quassel@pool-108-34-238-21.prvdri.fios.verizon.net] has quit [Ping timeout: 480 seconds] 03:51 -!- YuGiOhJCJ [~YuGiOhJCJ@00021b1f.user.oftc.net] has joined #dri-devel 03:56 -!- julio7359 [~julio7359@75.172.139.251] has quit [Ping timeout: 480 seconds] 04:03 -!- Zopolis4 [uid504804@id-504804.ilkley.irccloud.com] has joined #dri-devel 04:09 -!- caveman [~caveman@0002bdf0.user.oftc.net] has quit [Ping timeout: 480 seconds] 04:11 -!- nchery [~nchery@50.39.99.32] has joined #intel-gfx 04:11 -!- nchery [~nchery@50.39.99.32] has joined #intel-3d 04:11 -!- nchery [~nchery@50.39.99.32] has joined #dri-devel 04:11 -!- pochu_ [~pochu@87.red-88-30-59.staticip.rima-tde.net] has joined #wayland 04:11 -!- pochu_ [~pochu@87.red-88-30-59.staticip.rima-tde.net] has joined #dri-devel 04:13 -!- pochu [~pochu@87.red-88-30-59.staticip.rima-tde.net] has quit [Ping timeout: 480 seconds] 04:13 -!- pochu [~pochu@87.red-88-30-59.staticip.rima-tde.net] has quit [Ping timeout: 480 seconds] 04:17 -!- caveman [~caveman@0002bdf0.user.oftc.net] has joined #wayland 04:31 -!- ice9 [~ice9@0001f41b.user.oftc.net] has joined #dri-devel 04:31 -!- ice9 [~ice9@0001f41b.user.oftc.net] has joined #intel-gfx 04:36 -!- otavio__ [~otavio@200-203-24-19.user3p.brasiltelecom.net.br] has joined #etnaviv 04:37 -!- otavio_ [~otavio@200-203-24-19.user3p.brasiltelecom.net.br] has quit [Ping timeout: 480 seconds] 04:37 -!- bmodem [~Thunderbi@134.134.137.84] has joined #intel-gfx 04:37 -!- bmodem [~Thunderbi@134.134.137.84] has joined #dri-devel 04:45 -!- swatish2 [~swatish2@134.134.139.71] has joined #intel-gfx 04:48 -!- feto_bastardo4 [~fetobasta@83.172.209.35.bc.googleusercontent.com] has joined #freedesktop 04:53 -!- heyman94 [~heyman@7YZAACOUU.tor-irc.dnsbl.oftc.net] has left #nouveau [] 04:56 -!- kts [~kts@103.73.236.62] has joined #dri-devel 04:56 -!- kts [~kts@103.73.236.62] has joined #intel-gfx 04:56 -!- kts [~kts@103.73.236.62] has joined #intel-3d 04:56 -!- kts [~kts@103.73.236.62] has joined #wayland 04:59 -!- feto_bastardo45 [~fetobasta@83.172.209.35.bc.googleusercontent.com] has joined #freedesktop 05:01 -!- feto_bastardo4 [~fetobasta@83.172.209.35.bc.googleusercontent.com] has quit [Remote host closed the connection] 05:03 -!- feto_bastardo45 [~fetobasta@83.172.209.35.bc.googleusercontent.com] has quit [] 05:04 -!- feto_bastardo45 [~fetobasta@83.172.209.35.bc.googleusercontent.com] has joined #freedesktop 05:05 -!- mmu_man [~revol@82-65-227-82.subs.proxad.net] has quit [Ping timeout: 480 seconds] 05:13 -!- ngcortes [~ngcortes@134.134.139.71] has quit [Read error: Connection reset by peer] 05:13 -!- ngcortes [~ngcortes@134.134.139.71] has quit [Read error: Connection reset by peer] 05:13 -!- ngcortes [~ngcortes@134.134.139.71] has quit [Read error: Connection reset by peer] 05:24 -!- swatish2 [~swatish2@134.134.139.71] has quit [Read error: Connection reset by peer] 05:24 -!- pallavim [~pallavim@192.55.55.52] has quit [Ping timeout: 480 seconds] 05:24 -!- pallavim [~pallavim@192.55.55.52] has quit [Ping timeout: 480 seconds] 05:26 -!- slattann [~slattann@134.134.139.84] has joined #wayland 05:30 -!- pallavim [~pallavim@192.55.55.52] has joined #intel-gfx 05:30 -!- pallavim [~pallavim@192.55.55.52] has joined #dri-devel 05:33 -!- heat [~heat@0002b861.user.oftc.net] has quit [Ping timeout: 480 seconds] 05:33 -!- heat [~heat@0002b861.user.oftc.net] has quit [Ping timeout: 480 seconds] 05:33 -!- heat [~heat@0002b861.user.oftc.net] has quit [Ping timeout: 480 seconds] 05:34 -!- kzd_ [~kzd@static-198-54-130-84.cust.tzulo.com] has quit [] 05:34 -!- kzd_ [~kzd@static-198-54-130-84.cust.tzulo.com] has quit [] 05:35 -!- feto_bastardo45 [~fetobasta@83.172.209.35.bc.googleusercontent.com] has quit [] 05:46 -!- kts [~kts@103.73.236.62] has quit [Quit: Konversation terminated!] 05:46 -!- kts [~kts@103.73.236.62] has quit [Quit: Konversation terminated!] 05:46 -!- kts [~kts@103.73.236.62] has quit [Quit: Konversation terminated!] 05:46 -!- kts [~kts@103.73.236.62] has quit [Quit: Konversation terminated!] 05:55 -!- pallavim [~pallavim@192.55.55.52] has quit [Ping timeout: 480 seconds] 05:55 -!- pallavim [~pallavim@192.55.55.52] has quit [Ping timeout: 480 seconds] 06:02 -!- swatish2 [~swatish2@134.134.139.87] has joined #intel-gfx 06:08 -!- champtar [~oftc-webi@2607:fea8:1b9f:c5b0::349] has joined #freedesktop 06:12 -!- nchery [~nchery@50.39.99.32] has quit [Ping timeout: 480 seconds] 06:12 -!- nchery [~nchery@50.39.99.32] has quit [Ping timeout: 480 seconds] 06:12 -!- nchery [~nchery@50.39.99.32] has quit [Ping timeout: 480 seconds] 06:18 -!- hogander [~jhogande@134.191.220.83] has joined #intel-gfx 06:19 -!- champtar [~oftc-webi@2607:fea8:1b9f:c5b0::349] has quit [Quit: Page closed] 06:27 -!- Tom^ [~tom@h-158-174-67-168.A159.priv.bahnhof.se] has quit [Ping timeout: 480 seconds] 06:30 -!- mvlad [~mvlad@2a02:2f08:4c03:f700:7656:3cff:fe3f:7ce9] has joined #dri-devel 06:30 -!- mvlad [~mvlad@2a02:2f08:4c03:f700:7656:3cff:fe3f:7ce9] has joined #wayland 06:30 -!- mvlad [~mvlad@2a02:2f08:4c03:f700:7656:3cff:fe3f:7ce9] has joined #etnaviv 06:30 -!- mvlad [~mvlad@2a02:2f08:4c03:f700:7656:3cff:fe3f:7ce9] has joined #freedesktop 06:34 -!- ybogdano [~ybogdano@134.134.139.85] has joined #freedesktop 06:34 -!- ybogdano [~ybogdano@134.134.139.85] has joined #intel-gfx 06:34 -!- ybogdano [~ybogdano@134.134.139.85] has joined #intel-3d 06:34 -!- ybogdano [~ybogdano@134.134.139.85] has joined #dri-devel 06:34 -!- ybogdano [~ybogdano@134.134.139.85] has joined #wayland 06:37 -!- pixelgeek [~quassel@134.134.137.89] has quit [Remote host closed the connection] 06:37 -!- pixelgeek [~quassel@134.134.137.89] has joined #intel-gfx 06:37 -!- gtristan [~tristan@223.38.35.165] has joined #freedesktop 06:40 -!- gtristan_ [~tristan@223.38.35.165] has joined #freedesktop 06:40 #wayland: < wlb> weston/main: Michael Olbrich * compositor/text-backend: use xzalloc everywhere https://gitlab.freedesktop.org/wayland/weston/commit/00f08ec79c51 compositor/text-backend.c desktop-shell/shell.c 06:40 #wayland: < wlb> weston Merge request !1178 merged \o/ (compositor/text-backend: use xzalloc everywhere https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1178) 06:40 -!- gtristan [~tristan@223.38.35.165] has quit [Read error: Connection reset by peer] 06:43 -!- ybogdano is now known as Guest6146 06:43 -!- ybogdano is now known as Guest6146 06:43 -!- ybogdano is now known as Guest6146 06:43 -!- ybogdano is now known as Guest6146 06:43 -!- ybogdano is now known as Guest6146 06:43 -!- Guest6101 is now known as ybogdano 06:43 -!- Guest6101 is now known as ybogdano 06:43 -!- Guest6101 is now known as ybogdano 06:43 -!- Guest6101 is now known as ybogdano 06:43 -!- Guest6101 is now known as ybogdano 06:43 -!- Zopolis4 [uid504804@id-504804.ilkley.irccloud.com] has quit [] 06:45 -!- Zopolis4 [uid504804@id-504804.ilkley.irccloud.com] has joined #dri-devel 06:48 #wayland: < wlb> weston/main: Philipp Zabel * backend-vnc: rename vnc_convert_damage to vnc_region_global_to_output https://gitlab.freedesktop.org/wayland/weston/commit/12a7e4e16358 libweston/backend-vnc/vnc.c 06:48 #wayland: < wlb> weston Merge request !1175 merged \o/ (backend-vnc: rename vnc_convert_damage to vnc_region_global_to_output https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1175) 06:49 -!- hardening [~quassel@arennes-655-1-19-105.w109-218.abo.wanadoo.fr] has joined #wayland 06:50 -!- Misanthr- [~Misanthro@212.102.35.133] has joined #nouveau 06:51 -!- fab [~fab@bellet.info] has joined #dri-devel 06:52 -!- JohnDoe_71Rus [~CLDX@80.78.195.138] has joined #radeon 06:56 -!- cheako [uid293319@id-293319.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity] 06:56 -!- cheako [uid293319@id-293319.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity] 06:56 -!- Misanthropos [~Misanthro@216.24.213.37] has quit [Ping timeout: 480 seconds] 07:00 -!- Misanthr- [~Misanthro@212.102.35.133] has quit [] 07:01 -!- gtristan_ [~tristan@223.38.35.165] has quit [Ping timeout: 480 seconds] 07:02 -!- Tom^ [~tom@h-158-174-67-168.A159.priv.bahnhof.se] has joined #nouveau 07:03 -!- lemonzest [~lemonzest@cpc86080-nott19-2-0-cust160.12-2.cable.virginm.net] has joined #dri-devel 07:03 -!- lemonzest [~lemonzest@cpc86080-nott19-2-0-cust160.12-2.cable.virginm.net] has joined #radeon 07:04 -!- molinari [~molinari@176-151-233-216.abo.bbox.fr] has joined #wayland 07:08 -!- smiles [~smiles@2409:8a00:db0:5800:c76:ca8d:a1a:d77b] has quit [Ping timeout: 480 seconds] 07:08 #dri-devel: < sergi> anholt_: It's solved and there is a proposal to uprev piglit in mesa https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21574 07:16 -!- molinari [~molinari@176-151-233-216.abo.bbox.fr] has quit [Ping timeout: 480 seconds] 07:18 -!- Guest6146 [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 07:18 -!- Guest6146 [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 07:18 -!- Guest6146 [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 07:18 -!- Guest6146 [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 07:18 -!- Guest6146 [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 07:26 -!- dcz_ [~dcz@dynamic-093-135-015-053.93.135.pool.telefonica.de] has joined #wayland 07:26 -!- hansg [~hans@2001:1c00:c32:7800:5bfa:a036:83f0:f9ec] has joined #dri-devel 07:27 -!- Misanthropos [~Misanthro@212.102.35.133] has joined #nouveau 07:30 -!- ricotz [~ricotz@155.133.215.226] has joined #nouveau 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:35 -!- alanc [~alanc@148.87.23.6] has joined #dri-devel 07:35 -!- alanc [~alanc@148.87.23.6] has joined #freedesktop 07:38 -!- molinari [~molinari@176-151-233-216.abo.bbox.fr] has joined #wayland 07:39 -!- xmn [~xmn@cpe-72-225-198-203.nyc.res.rr.com] has quit [Ping timeout: 480 seconds] 07:42 -!- Jeremy_Rand_Talos [~Jeremy_Ra@8L3AADI27.tor-irc.dnsbl.oftc.net] has quit [Remote host closed the connection] 07:42 -!- Jeremy_Rand_Talos [~Jeremy_Ra@7YZAACPCV.tor-irc.dnsbl.oftc.net] has joined #dri-devel 07:44 -!- srslypascal is now known as Guest6148 07:45 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has joined #dri-devel 07:51 -!- Guest6148 [~srslypasc@0002bff5.user.oftc.net] has quit [Ping timeout: 480 seconds] 07:52 -!- jsa [~jsaarine@134.191.221.82] has joined #intel-gfx 07:55 -!- fab [~fab@bellet.info] has quit [Quit: fab] 07:55 -!- slattann [~slattann@134.134.139.84] has quit [Read error: Connection reset by peer] 07:56 -!- slattann [~slattann@134.134.139.84] has joined #wayland 07:58 -!- sghuge [~sagar@134.134.137.86] has quit [Remote host closed the connection] 07:58 -!- sghuge [~sagar@134.134.137.86] has quit [Remote host closed the connection] 07:58 -!- sghuge [~sagar@134.134.137.86] has quit [Remote host closed the connection] 07:58 -!- sghuge [~sagar@134.134.137.86] has joined #intel-3d 07:58 -!- sghuge [~sagar@134.134.137.86] has joined #intel-gfx 07:58 -!- sghuge [~sagar@134.134.137.86] has joined #dri-devel 08:03 -!- MajorBiscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has joined #dri-devel 08:03 -!- MajorBiscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has joined #freedesktop 08:03 -!- MajorBiscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has joined #intel-gfx 08:03 -!- MajorBiscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has joined #nouveau 08:03 -!- MajorBiscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has joined #radeon 08:03 -!- MajorBiscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has joined #wayland 08:04 -!- tzimmermann [~tzimmerma@2001:9e8:21d0:f200:f72:4873:8276:a047] has joined #dri-devel 08:04 -!- tzimmermann [~tzimmerma@2001:9e8:21d0:f200:f72:4873:8276:a047] has joined #intel-gfx 08:04 -!- tzimmermann [~tzimmerma@2001:9e8:21d0:f200:f72:4873:8276:a047] has joined #nouveau 08:04 -!- tzimmermann [~tzimmerma@2001:9e8:21d0:f200:f72:4873:8276:a047] has joined #radeon 08:04 -!- tzimmermann [~tzimmerma@2001:9e8:21d0:f200:f72:4873:8276:a047] has joined #wayland 08:05 -!- nchery [~nchery@50.39.99.32] has joined #intel-gfx 08:05 -!- nchery [~nchery@50.39.99.32] has joined #intel-3d 08:05 -!- nchery [~nchery@50.39.99.32] has joined #dri-devel 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:12 -!- mvchtz [~ubuntu@athedsl-149776.home.otenet.gr] has quit [Remote host closed the connection] 08:12 -!- mvchtz [~ubuntu@athedsl-149776.home.otenet.gr] has quit [Remote host closed the connection] 08:12 -!- mvchtz [~ubuntu@2a02:587:620e:14a:ba27:ebff:fe04:cdd6] has joined #radeon 08:12 -!- mvchtz [~ubuntu@2a02:587:620e:14a:ba27:ebff:fe04:cdd6] has joined #intel-gfx 08:28 -!- fab [~fab@134.214.236.142] has joined #dri-devel 08:30 -!- Deluxe [~Deluxe@37-48-49-128.nat.epc.tmcz.cz] has joined #radeon 08:31 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has quit [Quit: Leaving] 08:34 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #dri-devel 08:34 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #etnaviv 08:35 -!- fab [~fab@134.214.236.142] has quit [Quit: fab] 08:35 -!- fab [~fab@134.214.236.142] has joined #dri-devel 08:36 -!- Misanthropos [~Misanthro@212.102.35.133] has quit [Ping timeout: 480 seconds] 08:37 -!- rv1sr [~rv1sr@0002da44.user.oftc.net] has joined #wayland 08:38 -!- manuel1985 [~manuel198@62.99.131.178] has joined #wayland 08:38 -!- kts [~kts@103.73.237.85] has joined #dri-devel 08:38 -!- kts [~kts@103.73.237.85] has joined #intel-gfx 08:38 -!- kts [~kts@103.73.237.85] has joined #intel-3d 08:38 -!- kts [~kts@103.73.237.85] has joined #wayland 08:39 -!- Pr4x [~oftc-webi@43-4-133-N4.customer.vsm.sh] has joined #dri-devel 08:41 -!- Pr4x [~oftc-webi@43-4-133-N4.customer.vsm.sh] has quit [Remote host closed the connection] 08:41 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has joined #dri-devel 08:42 -!- Misanthropos [~Misanthro@154.47.21.148] has joined #nouveau 08:43 -!- nchery [~nchery@50.39.99.32] has quit [Quit: Leaving] 08:43 -!- nchery [~nchery@50.39.99.32] has quit [Quit: Leaving] 08:43 -!- nchery [~nchery@50.39.99.32] has quit [Quit: Leaving] 08:50 -!- Wolf481pl is now known as Wolf480pl 08:50 -!- Wolf481pl is now known as Wolf480pl 08:51 -!- slisovsk [~slisovsk@134.134.139.71] has joined #intel-gfx 09:01 -!- vliaskov [~vliaskov@dynamic-077-188-078-191.77.188.pool.telefonica.de] has joined #dri-devel 09:01 -!- vliaskov [~vliaskov@dynamic-077-188-078-191.77.188.pool.telefonica.de] has joined #nouveau 09:03 -!- apinheiro [~infapi00@fanzine2.igalia.com] has joined #dri-devel 09:05 -!- gtristan [~tristan@223.38.36.13] has joined #freedesktop 09:05 -!- gtristan [~tristan@223.38.36.13] has quit [Remote host closed the connection] 09:06 -!- gtristan [~tristan@223.38.36.13] has joined #freedesktop 09:09 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Ping timeout: 480 seconds] 09:09 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Ping timeout: 480 seconds] 09:10 -!- smiles [~smiles@2409:8a00:db0:5800:c76:ca8d:a1a:d77b] has joined #dri-devel 09:11 -!- rasterman [~rasterman@cpc99584-brnt1-2-0-cust1380.4-2.cable.virginm.net] has joined #dri-devel 09:11 -!- rasterman [~rasterman@cpc99584-brnt1-2-0-cust1380.4-2.cable.virginm.net] has joined #wayland 09:14 -!- lynxeye [~lynxeye@2a02:560:58ef:c500:20e1:7881:a58b:630d] has joined #etnaviv 09:14 -!- lynxeye [~lynxeye@2a02:560:58ef:c500:20e1:7881:a58b:630d] has joined #dri-devel 09:18 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #etnaviv 09:18 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #dri-devel 09:18 -!- djbw [~djbw@192.55.55.56] has quit [Read error: Connection reset by peer] 09:22 -!- BCMM [~BCMM@00026736.user.oftc.net] has joined #radeon 09:25 -!- Major_Biscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has joined #dri-devel 09:25 -!- Major_Biscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has joined #freedesktop 09:25 -!- Major_Biscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has joined #intel-gfx 09:25 -!- Major_Biscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has joined #nouveau 09:25 -!- Major_Biscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has joined #radeon 09:25 -!- Major_Biscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has joined #wayland 09:27 -!- MajorBiscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has quit [Ping timeout: 480 seconds] 09:27 -!- MajorBiscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has quit [Ping timeout: 480 seconds] 09:27 -!- MajorBiscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has quit [Ping timeout: 480 seconds] 09:27 -!- MajorBiscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has quit [Ping timeout: 480 seconds] 09:27 -!- MajorBiscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has quit [Ping timeout: 480 seconds] 09:27 -!- MajorBiscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has quit [Ping timeout: 480 seconds] 09:28 -!- slisovsk [~slisovsk@134.134.139.71] has quit [] 09:29 -!- Fxzxmic [~fxzxmic@120.209.180.200] has joined #wayland 09:36 -!- sgruszka [~sgruszka@134.191.220.85] has joined #dri-devel 09:39 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has joined #etnaviv 09:39 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has joined #dri-devel 09:41 -!- Deluxe [~Deluxe@37-48-49-128.nat.epc.tmcz.cz] has quit [Ping timeout: 480 seconds] 09:42 -!- jagan_ [~oftc-webi@2405:201:c00a:a1ce:ab7c:78b8:6683:4ba4] has joined #dri-devel 09:43 -!- jagan_ [~oftc-webi@2405:201:c00a:a1ce:ab7c:78b8:6683:4ba4] has quit [] 09:43 -!- jagan_ [~oftc-webi@2405:201:c00a:a1ce:ab7c:78b8:6683:4ba4] has joined #dri-devel 09:44 -!- slattann [~slattann@134.134.139.84] has quit [Ping timeout: 480 seconds] 09:57 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #dri-devel 09:57 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #freedesktop 09:57 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #intel-3d 09:57 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #intel-gfx 09:57 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #nouveau 09:57 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #radeon 09:57 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #wayland 09:57 -!- manuel_ [~manuel198@62.99.131.178] has joined #wayland 09:59 -!- Deluxe [~Deluxe@37-48-49-128.nat.epc.tmcz.cz] has joined #radeon 09:59 -!- Fxzx_mic [~fxzxmic@120.209.180.200] has joined #wayland 10:03 #dri-devel: < javierm> tzimmermann: are you following this thread? https://lists.freedesktop.org/archives/dri-devel/2023-February/392936.html 10:03 #dri-devel: < javierm> tzimmermann: I would like to know your opinion since you were also involved in the nomodeset cleanups 10:03 -!- emanuele-em_ [~oftc-webi@host-79-21-170-137.retail.telecomitalia.it] has joined #dri-devel 10:03 -!- manuel1985 [~manuel198@62.99.131.178] has quit [Ping timeout: 480 seconds] 10:03 -!- Fxzxmic [~fxzxmic@120.209.180.200] has quit [Ping timeout: 480 seconds] 10:07 -!- Fxzxmic [~fxzxmic@120.209.180.200] has joined #wayland 10:08 -!- swatish2 [~swatish2@134.134.139.87] has quit [Ping timeout: 480 seconds] 10:11 -!- Fxzx_mic [~fxzxmic@120.209.180.200] has quit [Ping timeout: 480 seconds] 10:11 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Ping timeout: 480 seconds] 10:11 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Ping timeout: 480 seconds] 10:14 -!- Deluxe [~Deluxe@37-48-49-128.nat.epc.tmcz.cz] has quit [Ping timeout: 480 seconds] 10:25 #intel-gfx: < jsa> Jani & all : drm-tip broken 10:25 -!- mi6x3m [~mi6x3m@0002d9fe.user.oftc.net] has joined #dri-devel 10:26 -!- Deluxe [~Deluxe@89-24-43-114.nat.epc.tmcz.cz] has joined #radeon 10:26 #dri-devel: < mi6x3m> hey, can anyone of you mesa devs explain to me how anv_GetPhysicalDeviceFeatures2 is mapped to GetPhysicalDeviceFeatures2 at runtime? 10:27 #dri-devel: < mi6x3m> i dont find any reference to anv_GetPhysicalDeviceFeatures2 other than the definition 10:27 -!- swatish2 [~swatish2@134.134.137.87] has joined #intel-gfx 10:27 #dri-devel: < mi6x3m> so I figured the string anv_ is added to GetPhysicalDeviceFeatures2 SOMEWHERE to resolve it 10:27 #dri-devel: < mi6x3m> but i cant find the place :( 10:28 #wayland: < emersion> ofourdan: do you remember why the number of bits is stored instead of the actual size in !188? 10:29 -!- phasta [~phasta@82.207.245.0] has joined #dri-devel 10:29 -!- phasta [~phasta@82.207.245.0] has joined #nouveau 10:29 -!- phasta [~phasta@82.207.245.0] has joined #freedesktop 10:32 #freedesktop: < mupuf> bentiss: the auto-deactivation-bot looks suspicious: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/504 10:33 #freedesktop: < mupuf> sorry, there is no such bot, let me find the gitlab option you clicked 10:34 #freedesktop: < bentiss> mupuf: https://gitlab.freedesktop.org/admin/application_settings/general -> Dormant users 10:34 #freedesktop: < mupuf> yeah, I found it 10:35 #freedesktop: < hakzsam> https://gitlab.freedesktop.org/mesa/mesa/-/jobs/37175337 error 500? 10:35 #freedesktop: < mupuf> bentiss: right, so this seems to be a gitlab bug then. The user logged in less than a week ago... and yet it was automatically deactivated 10:36 #freedesktop: < bentiss> mupuf: yep :) 10:36 #freedesktop: < mupuf> I wonder if this may be related to whenever we update gitlab 10:36 #freedesktop: < bentiss> honestly not sure it helps a lot to have this feature enabled 10:36 -!- Company [~Company@ip1f1264d8.dynamic.kabel-deutschland.de] has joined #dri-devel 10:36 -!- Company [~Company@ip1f1264d8.dynamic.kabel-deutschland.de] has joined #wayland 10:39 #freedesktop: < mupuf> Yeah, possibly not :s 10:40 #freedesktop: < mupuf> Let's try 1 year. If we still hear about people getting deactivated, we'll disable the feature 10:40 #freedesktop: < mupuf> done 10:43 #intel-gfx: < jani> jsa: please define broken ;) 10:45 #freedesktop: < bentiss> thx 10:47 -!- gtristan [~tristan@223.38.36.13] has quit [Ping timeout: 480 seconds] 10:49 -!- emanuele-em_ [~oftc-webi@host-79-21-170-137.retail.telecomitalia.it] has quit [] 10:50 -!- phasta [~phasta@82.207.245.0] has quit [Quit: Leaving] 10:50 -!- phasta [~phasta@82.207.245.0] has quit [Quit: Leaving] 10:50 -!- phasta [~phasta@82.207.245.0] has quit [Quit: Leaving] 10:51 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #etnaviv 10:51 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #dri-devel 10:53 -!- phasta [~phasta@82.207.245.0] has joined #dri-devel 10:53 -!- phasta [~phasta@82.207.245.0] has joined #nouveau 10:53 -!- phasta [~phasta@82.207.245.0] has joined #freedesktop 10:54 -!- diogenes_oftc [~diogenes_@user-5-173-112-20.play-internet.pl] has joined #nouveau 10:57 -!- vivia [~vivia@0002b905.user.oftc.net] has joined #freedesktop 10:57 -!- XYZ [~XYZ@37-48-42-64.nat.epc.tmcz.cz] has joined #radeon 10:57 #freedesktop: < vivia> daniels: I clicked here out of curiosity and it mentions Freenode https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home 11:00 -!- Fxzx_mic [~fxzxmic@120.209.180.200] has joined #wayland 11:02 -!- hansg [~hans@2001:1c00:c32:7800:5bfa:a036:83f0:f9ec] has quit [Quit: Leaving] 11:02 #dri-devel: < kj> I think they get generated at build time with src/vulkan/util/vk_entrypoints_gen.py so you'll see vk_entrypoints_gen in the meson.build 11:03 #dri-devel: < kj> But I don't really know all the magic behind it of how it works exactly 11:03 #dri-devel: < vsyrjala> digetx: your stuff broke i915. https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12790/fi-snb-2520m/igt@gem_exec_fence@basic-busy.html 11:04 #dri-devel: < mi6x3m> kj, aha!! important piece of intel, thank you 11:04 #dri-devel: < mi6x3m> let me check 11:04 -!- Fxzxmic [~fxzxmic@120.209.180.200] has quit [Ping timeout: 480 seconds] 11:05 #freedesktop: < mupuf> vivia: oops, I had fixed that... but did not save it 11:05 #freedesktop: < mupuf> thanks! 11:08 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has quit [Ping timeout: 480 seconds] 11:08 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has quit [Ping timeout: 480 seconds] 11:12 #freedesktop: < mupuf> gitlab's wiki page history is ridiculously bad. No diffing? 11:14 -!- paulk-bis [~paulk@vpn-0-22.aquilenet.fr] has quit [Read error: Connection reset by peer] 11:14 -!- paulk-bis [~paulk@vpn-0-22.aquilenet.fr] has quit [Read error: Connection reset by peer] 11:14 -!- paulk [~paulk@vpn-0-22.aquilenet.fr] has joined #dri-devel 11:14 -!- paulk [~paulk@vpn-0-22.aquilenet.fr] has joined #wayland 11:15 #dri-devel: < tzimmermann> javierm, thanks for the review 11:15 -!- Adrinael_ [adrinael@87-92-68-242.bb.dnainternet.fi] has joined #intel-gfx 11:15 -!- Adrinael_ [adrinael@87-92-68-242.bb.dnainternet.fi] has joined #dri-devel 11:15 #dri-devel: < tzimmermann> javierm, i've seen the virtio patch. but it seems unrelated to actual nomodeset option 11:15 #intel-gfx: < jsa> See https://intel-gfx-ci.01.org/tree/drm-tip/index.html? 11:16 #intel-gfx: < jsa> All systems aborting bat run.... 11:16 #intel-gfx: < jsa> <4> [35.452365] WARNING: CPU: 8 PID: 1083 at drivers/gpu/drm/drm_gem_shmem_helper.c:243 drm_gem_shmem_pin+0x42/0x90 [drm_shmem_helper] 11:17 #intel-gfx: < jsa> I assume starting looking ane setup: https://intel-gfx-ci.01.org/tree/drm-tip/fi-tgl-1115g4.html => https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12784/git-log-oneline.txt 11:17 #intel-gfx: < jsa> ane => one. 11:17 #freedesktop: < mupuf> daniels, bentiss, emersion: Anyone has any objection for me to enable the "admin mode"? https://gitlab.freedesktop.org/help/user/admin_area/settings/sign_in_restrictions#admin-mode 11:18 #freedesktop: < mupuf> This should be relatively transparent: only when you request to act as an admin will you have the rights to access the admin or projects you don't normally have access to 11:18 #freedesktop: < mupuf> this does not apply to tokens or git pushes, unfortunately... but that's a start! 11:19 #dri-devel: < javierm> tzimmermann: not quite, the goal of the patch is to disable modsetting while still keeping the rendering part 11:19 #dri-devel: < tzimmermann> javierm, IIRC there was some discussion about the semantics of nomodeset when we merged it. and IIRC we decide to ignore those corner cases then. that's back on the table now, i guess 11:20 #freedesktop: < emersion> sure 11:20 -!- Adrinael [adrinael@dsl-hkibng21-54f86e-80.dhcp.inet.fi] has quit [Ping timeout: 480 seconds] 11:20 -!- Adrinael [adrinael@dsl-hkibng21-54f86e-80.dhcp.inet.fi] has quit [Ping timeout: 480 seconds] 11:20 #dri-devel: < tzimmermann> TBH, i think i'd prefer a module option here. 11:20 #dri-devel: < javierm> tzimmermann: yeah, we didn't add nomodeset handling to DRM only drivers (i.e: that have DRIVER_RENDER but no DRIVER_MODESET) 11:20 #dri-devel: < tzimmermann> let me type up a reply mail 11:21 #dri-devel: < javierm> tzimmermann: a separate option than virtio-gpu.modeset then? 11:21 #dri-devel: < tzimmermann> no 11:21 #dri-devel: < tzimmermann> let me take a look. if there's already such an option, we wouldn't need another 11:21 #dri-devel: < javierm> tzimmermann: yeah, that's what my point: https://lists.freedesktop.org/archives/dri-devel/2023-February/393399.html 11:23 #dri-devel: < javierm> *that was 11:23 -!- Adrinael_ is now known as Adrinael 11:23 -!- Adrinael_ is now known as Adrinael 11:28 -!- XYZ [~XYZ@37-48-42-64.nat.epc.tmcz.cz] has quit [Ping timeout: 480 seconds] 11:28 #wayland: < wlb> wayland/main: Simon Ser * 5 commits https://gitlab.freedesktop.org/wayland/wayland/compare/ab526f8d7c80433effd01c1994d50c618c0b7207...d72f9007c36f2f8ad2dc26178545e8a7f5b993a0 11:28 #wayland: < wlb> wayland Merge request !282 merged \o/ (client: Improve handling of event queue destruction with attached proxies https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/282) 11:29 -!- XYZ [~XYZ@37-48-42-64.nat.epc.tmcz.cz] has joined #radeon 11:31 -!- mi6x3m [~mi6x3m@0002d9fe.user.oftc.net] has quit [Quit: Leaving] 11:31 #freedesktop: < vivia> mupuf: thanks :) 11:35 #dri-devel: < digetx> vsyrjala: afaics from the log, it's the vgem problem, not i915; looking at it, thanks 11:39 -!- bmodem [~Thunderbi@134.134.137.84] has quit [Ping timeout: 480 seconds] 11:39 -!- bmodem [~Thunderbi@134.134.137.84] has quit [Ping timeout: 480 seconds] 11:46 #dri-devel: < DavidHeidelberg[m]> I would love to merge CI sections today, any concerns? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20272 11:46 -!- XYZ89 [~XYZ@37-48-42-64.nat.epc.tmcz.cz] has joined #radeon 11:47 -!- Fxzxmic [~fxzxmic@120.209.180.200] has joined #wayland 11:48 -!- dviola [~diego@0002b89a.user.oftc.net] has joined #intel-gfx 11:48 -!- dviola [~diego@0002b89a.user.oftc.net] has joined #intel-3d 11:48 -!- dviola [~diego@0002b89a.user.oftc.net] has joined #radeon 11:48 -!- dviola [~diego@0002b89a.user.oftc.net] has joined #nouveau 11:48 -!- dviola [~diego@0002b89a.user.oftc.net] has joined #dri-devel 11:48 -!- XYZ [~XYZ@37-48-42-64.nat.epc.tmcz.cz] has quit [Ping timeout: 480 seconds] 11:49 -!- Fxzx_mic [~fxzxmic@120.209.180.200] has quit [Ping timeout: 480 seconds] 11:53 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Ping timeout: 480 seconds] 11:53 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Ping timeout: 480 seconds] 11:56 -!- Fxzx_mic [~fxzxmic@120.209.180.200] has joined #wayland 12:00 #dri-devel: < javierm> tzimmermann: thanks for your answer. I agree with your thoughts 12:01 #dri-devel: < javierm> tzimmermann: I'll let others decide what should be done for this particular driver, but we should think about the 'nomodeset' and modules 'modeset' params semantics and try to make it consistent 12:03 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #etnaviv 12:03 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #dri-devel 12:03 -!- Fxzxmic [~fxzxmic@120.209.180.200] has quit [Ping timeout: 480 seconds] 12:06 #dri-devel: < tzimmermann> javierm, wasn't that super complicated? IIRC we couldn't outright remove pre-existing modeset parameters because too many blogs, comments, guides refered to it? 12:06 -!- aravind [~aravind@192.55.54.51] has quit [Ping timeout: 480 seconds] 12:06 -!- aravind [~aravind@192.55.54.51] has quit [Ping timeout: 480 seconds] 12:06 #dri-devel: < javierm> tzimmermann: I didn't mean to remove 'nomodeset' or modules 'modeset' but just make the behaviour consistent 12:06 #dri-devel: < javierm> i.e: make all drivers to fail probing for example 12:07 -!- aravind [~aravind@134.134.137.85] has joined #intel-gfx 12:07 -!- aravind [~aravind@134.134.137.85] has joined #dri-devel 12:07 #dri-devel: < tzimmermann> javierm, we do this for modeset, don't we? 12:07 #dri-devel: < tzimmermann> they all fail registering/probing 12:07 #dri-devel: < javierm> tzimmermann: as mentioned in the thread at least i915 and nouveau only disable the KMS part IIUC 12:08 #dri-devel: < javierm> so I wonder if in that case the aperture helpers would kick the firmware-provided framebuffer anyways 12:10 -!- gtristan [~tristan@223.38.36.245] has joined #freedesktop 12:10 #dri-devel: < tzimmermann> nouveau apparently doesn't register 12:11 #dri-devel: < vsyrjala> iirc i915 becomes a dead husk if you use that 12:12 #dri-devel: < tzimmermann> i915 doesn't register either 12:12 #dri-devel: < tzimmermann> yeah 12:12 #freedreno: < lumag> robclark, regarding the MR vs patchwork. I noticed that intel guys have some of the tests enabled on patchwork.fdo.org, including the simple ones like checkpatch/docs/etc. Do you know if it would be possible to enable a subset of their tests for the patches hitting freedreno's patchwork? 12:12 #dri-devel: < tzimmermann> so do all the other drivers with modeset 12:13 #dri-devel: < tzimmermann> that's why i called it repurposing modeset 12:13 #dri-devel: < tzimmermann> virtgpu would then register, but as render-only driver 12:13 #dri-devel: < javierm> tzimmermann: right, sorry my bad. I just grepped the drivers that weren't doing a "return" after the check 12:14 #dri-devel: < tzimmermann> no worries, we've been fighting with the semantics ever since 12:14 -!- nerdopolis [~quassel@pool-108-34-238-21.prvdri.fios.verizon.net] has joined #wayland 12:14 #dri-devel: < tzimmermann> i guess we could do this for other drivers as well, if we convince maintainers 12:14 #dri-devel: < javierm> but I see now that both drivers check later if use_kms or nouveau_modeset respectively and return with no success 12:14 #dri-devel: < tzimmermann> that would be i915, nouveau, radeon 12:15 #dri-devel: < tzimmermann> i just don't know if anyone cares. i'm not even sure why virtio needs that option 12:16 #dri-devel: < vsyrjala> i915 already has a i915.disable_display. though all that does it claim all connectors are disconnected 12:16 #dri-devel: < tzimmermann> and a few other drivers only support modesetting (ast, mgag200, bochs) 12:17 #dri-devel: < vsyrjala> that's as far as we're willing to take it in i915. anything else would be madness when the display hardware is still actually present 12:18 -!- YuGiOhJCJ [~YuGiOhJCJ@00021b1f.user.oftc.net] has quit [Quit: YuGiOhJCJ] 12:19 #dri-devel: < vsyrjala> well, i guess we could take it a notch further by rejecting all kms ioctls, if that were possible. but we still need to initialze the full kms stuff internally 12:19 #dri-devel: < tzimmermann> vsyrjala, i tend to agree. i don't see the benefit of that option; besides 'because we can' 12:20 #dri-devel: < javierm> tzimmermann: yeah, those allow to disable modsetting (which is really disable register / probe) and to override the global 'nomodeset' param 12:21 -!- mowcat [~mowcat@host81-155-196-87.range81-155.btcentralplus.com] has joined #radeon 12:21 -!- gtristan [~tristan@223.38.36.245] has quit [Remote host closed the connection] 12:21 #dri-devel: < javierm> tzimmermann: it seems the goal is to reduce the attach surface since ChromeOS doesn't use virtio-gpu for KMS, only for rendering 12:22 #dri-devel: < javierm> *attack 12:22 -!- mmu_man [~revol@82-65-227-82.subs.proxad.net] has joined #nouveau 12:22 -!- gtristan [~tristan@223.38.36.245] has joined #freedesktop 12:22 #dri-devel: < javierm> tzimmermann: anyways, if all drivers fail to probe with either 'nomodeset' and the modules 'modeset=0' then I'm a happy camper and the semantics are consistent 12:23 #dri-devel: < javierm> even if the naming is confusing :) 12:23 -!- gtristan [~tristan@223.38.36.245] has quit [Remote host closed the connection] 12:24 #dri-devel: < tzimmermann> javierm, i've send an email about the real-world use of the option. 12:25 #dri-devel: < digetx> tzimmermann: robclark already said explicitly on the ML that the config option is for security reasons and nothing else 12:26 #dri-devel: < digetx> but yes, I suggested that the commit message should be improved 12:26 -!- gtristan [~tristan@223.38.36.245] has joined #freedesktop 12:27 #dri-devel: < tzimmermann> digitx, did he. i see two mails from rob. neither speaks of security 12:28 #dri-devel: < digetx> tzimmermann: https://lore.kernel.org/dri-devel/CAF6AEGsT8_o+v0vzGu1nyh6Z82pj8FnGUdMFc0Lq+4OWoSjRBQ@mail.gmail.com/ 12:28 #dri-devel: < tzimmermann> javierm, maybe we should warn if modeset is anything but -1? and then tell users to use nomodeset instead. https://elixir.bootlin.com/linux/v6.2/source/include/drm/drm_module.h#L62 12:29 #dri-devel: < javierm> tzimmermann: yeah, could be. I guess in practice though most people will just use 1 or 0 for this param, or just the global 'nomodeset' 12:29 #dri-devel: < javierm> tzimmermann: probably if you remove the per-module parameters nobody will even notice :) 12:30 #dri-devel: < tzimmermann> digitx, i didn't see this before. thanks 12:30 #dri-devel: < tzimmermann> it's still really vague AFAICT 12:31 #dri-devel: < tzimmermann> those modeset ioctls are DRM-wide. so why isn't this a DRM-wide option? 12:33 -!- Fxzx_mic [~fxzxmic@120.209.180.200] has quit [Quit: Konversation exit!] 12:35 #dri-devel: < javierm> tzimmermann: that's a very good point. It would make more sense to have a Kconfig option to just disable KMS then 12:35 #dri-devel: < javierm> so that drm_core_check_feature(dev, DRIVER_MODESET) will always return false for example 12:35 #dri-devel: < digetx> perhaps it could be a DRM-wide option as alternative; it's a global vs per-driver option preference, the global variant should work in Rob's case 12:36 -!- nobiz [~nobiz@0002d7e5.user.oftc.net] has quit [Quit: The Lounge - https://thelounge.chat] 12:36 #dri-devel: < javierm> digetx: yeah, because the only DRM driver that will be used in the VM will be virtio-gpu anyways 12:36 #dri-devel: < digetx> actually, not true :) there is option with passthrough gpu + virtiogpu 12:37 -!- nobiz [~nobiz@0002d7e5.user.oftc.net] has joined #wayland 12:37 -!- nobiz [~nobiz@0002d7e5.user.oftc.net] has quit [Remote host closed the connection] 12:37 #dri-devel: < digetx> and Google uses that case it too 12:40 #dri-devel: < javierm> digetx: ah, so they pass-through the host GPU and use the native DRM driver in the guest? I thought that they used the virtio-gpu native contexts support and that only used the mesa driver in the guest 12:40 #dri-devel: < javierm> but still virtio-gpu to tunnel the native DRM driver ioctls over virtio 12:40 -!- Fxzxmic [~fxzxmic@120.209.180.200] has joined #wayland 12:40 -!- Fxzxmic [~fxzxmic@120.209.180.200] has quit [] 12:40 -!- gtristan [~tristan@223.38.36.245] has quit [Remote host closed the connection] 12:41 -!- Fxzxmic [~fxzxmic@120.209.180.200] has joined #wayland 12:41 -!- kinkinkijkin [~kinkinkij@162.246.53.59] has joined #radeon 12:42 -!- gtristan [~tristan@223.38.36.245] has joined #freedesktop 12:42 #dri-devel: < digetx> there are multiple use-cases, depending on product; pass-through second host GPU + virtio-gpu is one variant, solely native context virtio-gpu is another 12:42 #dri-devel: < javierm> digetx: got it 12:43 -!- gtristan [~tristan@223.38.36.245] has quit [Remote host closed the connection] 12:44 -!- gtristan [~tristan@223.38.36.245] has joined #freedesktop 12:45 -!- gtristan [~tristan@223.38.36.245] has quit [Remote host closed the connection] 12:46 -!- gtristan [~tristan@223.38.36.245] has joined #freedesktop 12:46 -!- mowcat [~mowcat@host81-155-196-87.range81-155.btcentralplus.com] has quit [Remote host closed the connection] 12:50 #wayland: < pq> emersion, re: overscan; I think it comes from the older CRT having round corners and curved edges, and overscan making sure all the phosphor lights up properly, clipping image edges out in the process. :-) 12:51 -!- kts [~kts@103.73.237.85] has quit [Quit: Konversation terminated!] 12:51 -!- kts [~kts@103.73.237.85] has quit [Quit: Konversation terminated!] 12:51 -!- kts [~kts@103.73.237.85] has quit [Quit: Konversation terminated!] 12:51 -!- kts [~kts@103.73.237.85] has quit [Quit: Konversation terminated!] 12:51 #wayland: < emersion> aha, got these mixed up 12:51 #wayland: < pq> how wonderful that we still need to care about these things 12:51 #wayland: < emersion> cute, another CRT explanation for historical gfx stuff 12:52 #wayland: < emersion> yeah, really glad we have TVs with the latest and greatest technology 2023 has to offer 12:53 #wayland: < pq> also, since it was known that receiver CRT will clip, the broadcast has some cruft at the edges that then got clipped. 12:53 #wayland: < emersion> ok, so overscan is when clipping happens, and underscan is when there is letterboxing 12:53 #wayland: < emersion> (from a user PoV) 12:53 #wayland: < pq> meaning that also flat planels needed to clip as well -> overscan by default in TVs 12:53 #wayland: < emersion> oh, that's why 12:54 #wayland: < kennylevinsen> overscan by default makes me so very upset 12:54 #wayland: < emersion> i wonder if HDMI content type helps 12:54 #wayland: < emersion> ie, if I set HDMI content type, will it fix most TVs 12:54 #wayland: < vsyrjala> iirc no 12:54 #wayland: < pq> I believe HDMI has explicit under/overscan messages 12:55 #wayland: < pq> do TV's actually listen to those? ha ha... 12:55 #wayland: < vsyrjala> i don't recall if you can tell it to do anything. iirc it can tell you whether it indends to overscan vs. undescan for ce vs. it modes separately of course 12:55 #wayland: < pq> some do, some don't, and so we need a workaround 12:56 #wayland: < emersion> how does the source know how to set the margins correctly? 12:56 #wayland: < emersion> some EDID thing? 12:56 #wayland: < emersion> (can't remember of any) 12:56 #wayland: < pq> vsyrjala, oh gosh, it was a message in the wrong direction 12:56 #wayland: < emersion> i remember the user configuration UIs to setup margins though 12:57 #wayland: < emersion> ah, ok, so some vague CTA stuff may help 12:57 #wayland: < vsyrjala> hmm. there is under/overscan stuff in the avi infoframe 12:57 #wayland: < emersion> but we don't know whether we picked CE or IT… 12:57 #wayland: < pq> yeah, console games often(?) have margin setup UI 12:58 #wayland: < emersion> vsyrjala: separate from the bars stuff? 12:58 #wayland: < swick[m]> we really need a bit more info on modes for underscan, overscan and color range 12:59 #wayland: < swick[m]> or we just figure it out from the EDID and then compare the modes with the KMS modes 12:59 #wayland: < vsyrjala> emersion: yeah, and apparently we always set it for underscan. but i'm pretty sure many tvs still overscan 12:59 #wayland: < emersion> vsyrjala: we = drm core or i915, out of curiosity? 12:59 #wayland: < vsyrjala> drm_hdmi_avi_infoframe_from_display_mode 13:00 #wayland: < emersion> ah core, nice 13:00 -!- gtristan [~tristan@223.38.36.245] has quit [Remote host closed the connection] 13:00 #wayland: < emersion> since we set it, some TVs might obey and some might not, so margins really need to be user-configured 13:02 -!- feto_bastardo45 [~fetobasta@83.172.209.35.bc.googleusercontent.com] has joined #freedesktop 13:02 #wayland: < vsyrjala> looks like vcdb allows the sink to declare what kinds of scan it supports. separately for different kinds of modes of course :/ 13:03 #wayland: < vsyrjala> iirc i once saw some recommendation document for braodcast tv subtitle/etc placement. can't recall the specific numbers 13:04 -!- diogenes_oftc [~diogenes_@user-5-173-112-20.play-internet.pl] has quit [Quit: diogenes_oftc] 13:04 -!- feto_bastardo45 [~fetobasta@83.172.209.35.bc.googleusercontent.com] has quit [] 13:05 -!- feto_bastardo [~fetobasta@83.172.209.35.bc.googleusercontent.com] has joined #freedesktop 13:05 #wayland: < emersion> hm right, because you can also place "unimportant" details in the image area which will be potentially overscanned 13:05 #wayland: < emersion> which is impossible with the margins KMS props btw 13:06 #wayland: < zamundaaa[m]> "ok, so overscan is when clipping..." <- At least the overscan and underscan drm properties do the same thing afaik - they both pad the image on the borders 13:06 #wayland: < emersion> (i wish the margins were signalling only, and wouldn't actually do anything to the buffers…) 13:07 #wayland: < emersion> zamundaaa[m]: this discussion comes from https://lore.kernel.org/dri-devel/Y%2F3uqqeW73tiutgR@intel.com/T/#m0e2c1231ec816c28fa63713c236f09a7df951167 13:07 #wayland: < vsyrjala> dunno if anything uses the avi bars info tbh. also dp has no such thing afaik 13:07 #wayland: < emersion> the overscan and underscan props are not standard afaik 13:07 #wayland: < emersion> vsyrjala: ah, good to know 13:10 #wayland: < zamundaaa[m]> yes, they're not standard, but we support them in KWin 13:10 #wayland: < zamundaaa[m]> I do have one question on that topic... does this possibly affect DisplayPort at all, or is it only HDMI and old connectors like VGA? 13:11 #wayland: < emersion> ville has a branch with DP support for margins props 13:11 #wayland: < vsyrjala> not sure there are any native dp monitors that overscan. but dp->hdmi converters are certainly a thing 13:11 #wayland: < emersion> i haven't seen it on VGA 13:11 -!- kzd [~kzd@static-198-54-130-84.cust.tzulo.com] has joined #radeon 13:11 -!- kzd [~kzd@static-198-54-130-84.cust.tzulo.com] has joined #dri-devel 13:11 #wayland: < emersion> only HDMI and TVout 13:12 #freedesktop: < bentiss> mupuf: we can always set it, and if it's too bothering, disable it later :) 13:12 #wayland: < zamundaaa[m]> vsyrjala: We can detect those converts with the subconnector property though, right? 13:12 #freedesktop: < mupuf> I would indeed like to give it a try, but I also would like every admin to know 13:12 #wayland: < vsyrjala> they look like normal dp 13:13 #wayland: < vsyrjala> don't think we have any subconnector stuff hooked up for that 13:13 #wayland: < emersion> I think we do? 13:13 #wayland: < emersion> at least I've seen subconnector=HDMI on DP 13:14 #wayland: < emersion> the other intern next to me back when I was at Intel implemented it :P 13:15 #wayland: < vsyrjala> hmm. yes, apparently we do 13:15 #wayland: < vsyrjala> totally forgot that landed 13:17 #wayland: < vsyrjala> doesn't seem super robust though. my type-c -> hdmi dongle says 'Native' 13:17 -!- Dami_Lu [~lyn@110.191.179.216] has joined #wayland 13:18 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has quit [Ping timeout: 480 seconds] 13:19 #wayland: < emersion> ah, sad 13:19 -!- eroc1990 [~eroc1990@024-183-186-146.res.spectrum.com] has quit [Ping timeout: 480 seconds] 13:19 -!- JohnDoe_71Rus [~CLDX@80.78.195.138] has quit [] 13:20 #wayland: < emersion> maybe the interface type in the EDID could be more reliable, if set 13:20 #wayland: < emersion> or is this what the kernel uses? 13:20 #wayland: < vsyrjala> looks like it currently uses just the dpcd downstream port info 13:22 -!- ricotz [~ricotz@155.133.215.226] has quit [Quit: Leaving] 13:23 #wayland: < vsyrjala> i did tweak some of other dp->hdmi stuff to also check the edid. but that still wouldn't help here since this dongle apparently doesn't claim to be a branch device at all 13:23 #wayland: < emersion> rip 13:23 -!- eroc1990 [~eroc1990@024-183-186-146.res.spectrum.com] has joined #wayland 13:24 #wayland: < zamundaaa[m]> I guess we'll keep on showing the setting for all connector types that support it then... except maybe eDP, it really shouldn't need it 13:24 #wayland: < zamundaaa[m]> I hope 13:25 -!- vkareh [~vkareh@00026f70.user.oftc.net] has joined #freedesktop 13:26 #wayland: < vsyrjala> well, you might want to tweak the edp output size to get eg. 2x integer scaling or something like that 13:27 -!- eroc1990 [~eroc1990@024-183-186-146.res.spectrum.com] has quit [] 13:28 -!- eroc1990 [~eroc1990@024-183-186-146.res.spectrum.com] has joined #wayland 13:28 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has joined #dri-devel 13:29 #wayland: < zamundaaa[m]> I'm not sure what you're referring to. What does over/underscan have to do with integer scaling? 13:30 #wayland: < vsyrjala> you could use the margins for other things than overscan compensation 13:32 -!- fab [~fab@134.214.236.142] has quit [Quit: fab] 13:32 #wayland: < emersion> i'm not sure i'm following… 13:32 -!- Major_Biscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has quit [Ping timeout: 480 seconds] 13:32 -!- Major_Biscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has quit [Ping timeout: 480 seconds] 13:32 -!- Major_Biscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has quit [Ping timeout: 480 seconds] 13:32 -!- Major_Biscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has quit [Ping timeout: 480 seconds] 13:32 -!- Major_Biscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has quit [Ping timeout: 480 seconds] 13:32 -!- Major_Biscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has quit [Ping timeout: 480 seconds] 13:34 #wayland: < vsyrjala> say you have an emulator rendering at 320x200, you set the mode to match that, set scaling mode=fullscreem, and configure the margins to get an exact integer multiple upscale factor 13:35 -!- Major_Biscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has joined #dri-devel 13:35 -!- Major_Biscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has joined #freedesktop 13:35 -!- Major_Biscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has joined #intel-gfx 13:35 -!- Major_Biscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has joined #nouveau 13:35 -!- Major_Biscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has joined #radeon 13:35 -!- Major_Biscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has joined #wayland 13:36 #wayland: < pq> would that also work on a HDMI monitor that uses the infoframe bar data? 13:37 #wayland: < vsyrjala> for external connectors the panel will be driven with the mode the user passed in, so no 13:37 #wayland: < pq> ah 13:37 #wayland: < pq> "scaling mode" is not infoframe data? 13:38 -!- cheako [uid293319@id-293319.ilkley.irccloud.com] has joined #dri-devel 13:38 -!- cheako [uid293319@id-293319.ilkley.irccloud.com] has joined #radeon 13:38 #wayland: < zamundaaa[m]> vsyrjala: I'm only talking about hiding the setting from the user in our GUI, where we just give them a 0-100% overscan spinbox 13:38 -!- Fxzxmic [~fxzxmic@120.209.180.200] has quit [Ping timeout: 480 seconds] 13:38 #wayland: < vsyrjala> pq: no. it just specifies how we set up the scaler 13:38 #wayland: < zamundaaa[m]> That sounds like an interesting hack though, one that I hopefully never need to implement 13:39 -!- kts [~kts@103.73.236.54] has joined #dri-devel 13:39 -!- kts [~kts@103.73.236.54] has joined #intel-gfx 13:39 -!- kts [~kts@103.73.236.54] has joined #intel-3d 13:39 -!- kts [~kts@103.73.236.54] has joined #wayland 13:39 #wayland: < vsyrjala> i have occasionally pondered about exposing a 'fixed mode' property for all connector. would allow the same kind of scaler usage for external connectors that you get with internal ones atm 13:39 -!- phasta [~phasta@82.207.245.0] has quit [Quit: Leaving] 13:39 -!- phasta [~phasta@82.207.245.0] has quit [Quit: Leaving] 13:39 -!- phasta [~phasta@82.207.245.0] has quit [Quit: Leaving] 13:40 #wayland: < pq> use of the scaler inside an external monitor? 13:40 #wayland: < vsyrjala> scaler inside the gpu 13:40 #wayland: < pq> display controller? 13:40 #wayland: < vsyrjala> yes. right now with external monitors the monitor alwasy does the scaling 13:41 #wayland: < pq> oh, right, to avoid monitor's scaler 13:41 #wayland: < pq> but then, userspace can simply use the external monitor's native mode, and set up KMS scaling itself 13:42 #wayland: < vsyrjala> if you have scalable planes 13:42 #wayland: < pq> by plane props 13:43 #wayland: < pq> is it common for hardware to have a scaler in/after CRTC but not on planes? 13:43 -!- Moprius [~Thunderbi@189.40.86.205] has joined #radeon 13:43 -!- Moprius [~Thunderbi@189.40.86.205] has joined #wayland 13:43 #wayland: < vsyrjala> older intel hw was like that. well, there was usually one scalable sprite plane, primary/cursor could not be scaled 13:44 #wayland: < vsyrjala> and current intel hw has usually two scalers per crtc. each one can scale one plane or the whole crtc 13:45 -!- MajorBiscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has joined #dri-devel 13:45 -!- MajorBiscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has joined #freedesktop 13:45 -!- MajorBiscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has joined #intel-gfx 13:45 -!- MajorBiscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has joined #nouveau 13:45 -!- MajorBiscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has joined #radeon 13:45 -!- MajorBiscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has joined #wayland 13:45 #wayland: < vsyrjala> oh, and cursor still can't be scaled on its onw. only as part of the whole crtc 13:45 -!- apinheiro [~infapi00@fanzine2.igalia.com] has quit [Ping timeout: 480 seconds] 13:46 -!- Moprius [~Thunderbi@0002e253.user.oftc.net] has quit [] 13:46 -!- Moprius [~Thunderbi@0002e253.user.oftc.net] has quit [] 13:47 -!- Major_Biscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has quit [Ping timeout: 480 seconds] 13:47 -!- Major_Biscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has quit [Ping timeout: 480 seconds] 13:47 -!- Major_Biscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has quit [Ping timeout: 480 seconds] 13:47 -!- Major_Biscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has quit [Ping timeout: 480 seconds] 13:47 -!- Major_Biscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has quit [Ping timeout: 480 seconds] 13:47 -!- Major_Biscuit [~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a] has quit [Ping timeout: 480 seconds] 13:48 -!- kts [~kts@103.73.236.54] has quit [Quit: Konversation terminated!] 13:48 -!- kts [~kts@103.73.236.54] has quit [Quit: Konversation terminated!] 13:48 -!- kts [~kts@103.73.236.54] has quit [Quit: Konversation terminated!] 13:48 -!- kts [~kts@103.73.236.54] has quit [Quit: Konversation terminated!] 13:52 -!- kts [~kts@103.73.236.54] has joined #dri-devel 13:52 -!- kts [~kts@103.73.236.54] has joined #intel-gfx 13:52 -!- kts [~kts@103.73.236.54] has joined #intel-3d 13:52 -!- kts [~kts@103.73.236.54] has joined #wayland 13:54 -!- alanc [~alanc@148.87.23.6] has quit [Remote host closed the connection] 13:54 -!- alanc [~alanc@148.87.23.6] has quit [Remote host closed the connection] 13:55 #wayland: < vsyrjala> iirc there was some other proposal for defining the crtc viewport size independent of the mode via separate properties. but i think reconciling that with the way edp/lvds/etc. works currently would tricky 13:55 -!- ice9 [~ice9@0001f41b.user.oftc.net] has quit [Ping timeout: 480 seconds] 13:55 -!- ice9 [~ice9@0001f41b.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:02 -!- alanc [~alanc@148.87.23.6] has joined #dri-devel 14:02 -!- alanc [~alanc@148.87.23.6] has joined #freedesktop 14:03 -!- ricotz [~ricotz@155.133.216.159] has joined #nouveau 14:06 -!- aissen_ [~aissen@91-170-61-214.subs.proxad.net] has quit [] 14:06 -!- aissen_ [~aissen@91-170-61-214.subs.proxad.net] has quit [] 14:07 -!- aissen [~aissen@0002b546.user.oftc.net] has joined #intel-gfx 14:07 -!- aissen [~aissen@0002b546.user.oftc.net] has joined #dri-devel 14:08 -!- Fxzxmic [~fxzxmic@120.209.180.200] has joined #wayland 14:23 -!- Fxzx_mic [~fxzxmic@120.209.180.200] has joined #wayland 14:27 -!- Fxzxmic [~fxzxmic@120.209.180.200] has quit [Ping timeout: 480 seconds] 14:27 -!- xmn [~xmn@cpe-72-225-198-203.nyc.res.rr.com] has joined #radeon 14:32 -!- eroc1990 is now known as Guest6176 14:32 -!- eroc1990 [~eroc1990@024-183-186-146.res.spectrum.com] has joined #wayland 14:32 #dri-devel: < llyyr> I get `amdgpu: os_same_file_description couldn't determine if two DRM fds reference the same file description.` when starting any opengl application on Mesa built from the main branch, looking at the git logs there were some related changes to src/egl and it's probably also related to my issue #8394 14:32 #dri-devel: < llyyr> `mpv --no-config` can reproduce this, goes away with `mpv --no-config --gpu-api=vulkan` 14:37 -!- Guest6176 [~eroc1990@024-183-186-146.res.spectrum.com] has quit [Ping timeout: 480 seconds] 14:40 #dri-devel: < MrCooper> llyyr: that's on Linux? 14:40 #dri-devel: < llyyr> yes 14:41 #dri-devel: < llyyr> there's more info on https://gitlab.freedesktop.org/mesa/mesa/-/issues/8394 but i'm on sway/wayland 14:41 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has quit [Read error: Connection reset by peer] 14:41 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has quit [Read error: Connection reset by peer] 14:41 -!- jmdaemon [~jmdaemon@0002d6bd.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:41 #dri-devel: < emersion> with a recent-ish kernel? 14:41 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has joined #etnaviv 14:41 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has joined #dri-devel 14:41 #dri-devel: < llyyr> 6.1.2 14:41 #dri-devel: < llyyr> 6.1.12* 14:42 #dri-devel: < emersion> yeah 14:42 #dri-devel: < emersion> do you have the allow-kcmp Meson option set? 14:43 #dri-devel: < llyyr> it's set to auto 14:43 #dri-devel: < emersion> it's supposed to be enabled then… 14:44 #dri-devel: < llyyr> I just copied the options from my distro (tumbleweed) and set `Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec` because they don't build with those anymore 14:45 #dri-devel: < llyyr> also it works fine on 23.0.0 14:46 #freedreno: < robclark> lumag: given infinite resources (hw and people) anything is possible.. but the gitlab based kernel CI is inexpensive for us because it re-uses what we have for mesa CI.. a patchwork based CI farm would not (intel has a non-gitlab CI farm that predates gitlab.. and also a big pile of hw and a team to keep it all running.. we don't) 14:46 -!- Fxzxmic [~fxzxmic@120.209.180.200] has joined #wayland 14:46 #freedreno: < lumag> robclark, Yeah. I asked about a particular thing: checkpatch. 14:47 #dri-devel: < llyyr> !13422 is the only related change that's on the main branch but not on 23.0.0 14:47 #freedreno: < lumag> (and maybe docs check if that's what I think: check of kerneldoc tags) 14:47 #freedreno: < lumag> So, I'm not asking to replicate the gitlab CI infrastructure 14:49 -!- Fxzx_mic [~fxzxmic@120.209.180.200] has quit [Ping timeout: 480 seconds] 14:49 -!- Fxzxmic [~fxzxmic@120.209.180.200] has quit [] 14:50 -!- probablymoony [moony@hellomouse.net] has joined #dri-devel 14:50 -!- Fxzxmic [~fxzxmic@120.209.180.200] has joined #wayland 14:54 -!- heat [~heat@0002b861.user.oftc.net] has joined #intel-3d 14:54 -!- heat [~heat@0002b861.user.oftc.net] has joined #intel-gfx 14:54 -!- heat [~heat@0002b861.user.oftc.net] has joined #dri-devel 14:55 #dri-devel: < digetx> tzimmermann: you've re-added (likely accidentally) the wrong conflict resolution for drm-shmem to dim's rerere, don't you mind if I'll revert it? 14:55 #freedreno: < robclark> I guess at least it would take someone who knows a bit about patchwork to set that up.. and I guess some cloud thing somewhere to run the checks on 14:55 #dri-devel: < tzimmermann> digitx, ok 14:56 #dri-devel: < tzimmermann> i picked the dma-lock patch and the export_symbol_gpl patch IIRC 14:56 -!- yuq825 [~yuq@180.152.11.27] has left #lima [] 14:56 -!- yuq825 [~yuq@180.152.11.27] has left #dri-devel [] 14:56 #dri-devel: < tzimmermann> digetx ^ 14:56 #dri-devel: < vsyrjala> digetx: is a fix coming soon, or do we need to think about a revert? 14:57 -!- moony [moony@hellomouse.net] has quit [Ping timeout: 480 seconds] 14:57 #dri-devel: < mripard> marex: I'm sorry, I did my best 14:57 #dri-devel: < robclark> javierm, tzimmermann: for displaying guest windows there is a sort of "wayland proxy" that proxies the surfaces/fences to host compositor so kms in the guest is unused.. I'll respin the patch with a better commit msg after breakfast 14:57 #dri-devel: < jani> vsyrjala: is it broken on drm-misc-next too, or is this just about wrong conflict resolutions? 14:58 #dri-devel: < jani> I mean the conflict resolution could be wrong even if it builds 14:58 #dri-devel: < jani> idk 14:58 #dri-devel: < robclark> digetx: re: #ifdef vs #if IS_ENABLED() in the driver struct, #ifdef is already used (for example, for debugfs) nearby, so sticking with #ifdef there seemed more consistent.. but agree with your other comment about better commit msg 14:59 #dri-devel: < vsyrjala> jani: not sure. i presumed it's broken in general 15:00 #dri-devel: < digetx> vsyrjala: jani: that is a general issue, I'll try to fix it asap; if it will be taking too much time, then will be good to revert 15:01 #dri-devel: < javierm> robclark: I see. That's the virtio-wayland thing, right? 15:01 #dri-devel: < javierm> robclark: and I understood that was unused, it was just about compile vs runtime option 15:02 -!- gtristan [~tristan@223.38.36.71] has joined #freedesktop 15:04 #dri-devel: < tzimmermann> jani, vsyrjala, digetx, i'll take a look 15:04 #dri-devel: < digetx> vsyrjala: jani: that's a warning about a missing resv lock; the dma-buf locking rules became stricter since 6.2 kernel and they are enforced for shmem in the offending patch 15:04 #dri-devel: < digetx> robclark: ack 15:04 -!- Fxzx_mic [~fxzxmic@120.209.180.200] has joined #wayland 15:10 #dri-devel: < tzimmermann> digetx, vsyrjala, jani, i'm going to revert 67b7836d4458 ("drm/shmem-helper: Switch to reservation lock") 15:11 -!- Fxzxmic [~fxzxmic@120.209.180.200] has quit [Ping timeout: 480 seconds] 15:12 #dri-devel: < digetx> tzimmermann: okay, that perhaps the best option; will fix it without rushing and we'll try again 15:12 -!- vkareh [~vkareh@00026f70.user.oftc.net] has quit [Quit: Leaving] 15:13 -!- vkareh [~vkareh@00026f70.user.oftc.net] has joined #freedesktop 15:13 #etnaviv: < cmeissl[m]> tomeu: yes, or at least kind of. afaict after digging though the code in mesa it looks like the client would have to use the display node with kmsro to receive a scanout able dma buffer in the compositor. otherwise private memory would be allocated. But the wayland egl platform disables use of dmabuf feedback when I send card1 because it is not a render node. Sending the render node from etnaviv enables the use of dmabuf feedback, but 15:13 #etnaviv: < cmeissl[m]> kms->ro will be NULL. 15:13 -!- arsenm [~Adium@82.197.100.55] has quit [Quit: Leaving.] 15:13 #dri-devel: < tzimmermann> digetx, from what i can tell, the _pin code never acquires the lock 15:13 -!- Zopolis4 [uid504804@id-504804.ilkley.irccloud.com] has quit [] 15:13 -!- Fxzx_mic [~fxzxmic@120.209.180.200] has quit [Quit: Konversation exit!] 15:13 #dri-devel: < tzimmermann> and that is probably not hot-fixable 15:14 #dri-devel: < digetx> the shmem shouldn't get the pin lock, it should be a lock missing in other place for dma-buf exporting code path 15:14 #etnaviv: < cmeissl[m]> I opened https://gitlab.freedesktop.org/mesa/mesa/-/issues/8384 and asked in dri-devel, where I received some feedback about the problem. The last response from daniels suggests that it would be better to announce the render node as the main device and make the wayland platform code properly react on the scanout tranche target device. 15:15 #dri-devel: < jani> tzimmermann: eyballing the commit, does that revert also help with the conflict? 15:15 #dri-devel: < jani> *eye 15:16 #dri-devel: < digetx> tzimmermann: it's not a problem for the current drivers as they don't rely on the new resv locking rules 15:16 -!- gawin [~filip@0002cee1.user.oftc.net] has joined #dri-devel 15:16 #dri-devel: < tzimmermann> digetx, exactly. but not just there. enything that calls drm_gem_object_funcs now needs to hold that lock first 15:17 #dri-devel: < tzimmermann> jani, we'lkl see 15:17 #dri-devel: < digetx> tzimmermann: I've the same thought, will see where the lock is missing 15:18 #dri-devel: < tzimmermann> jani, if i post a revert, how do i get your CI to test it? 15:19 #dri-devel: < tzimmermann> digetx, you mention that you are working on a fix. do you want to try first? 15:19 #dri-devel: < robclark> javierm: yeah, virtio-wl (although I'd like to see it replaced w/ a virtgpu-wayland context type so we can get rid of a downstream guest kernel driver.. but no one has had time for that yet) 15:20 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has joined #freedesktop 15:20 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has joined #dri-devel 15:20 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has joined #radeon 15:20 -!- Deluxe [~Deluxe@89-24-43-114.nat.epc.tmcz.cz] has quit [Ping timeout: 480 seconds] 15:21 #dri-devel: < robclark> javierm: I'm in favor of a compile time option because it is easier to reason about.. which is important when you have four different host kernel LTS branches and three different guest kernels for different guest OSs (plus beta+stable and CrOS-LTS version branches for each of those) 15:21 #dri-devel: < digetx> tzimmermann: I already reproduced the reported warning, working on it, though also busy with other things in parallel 15:23 #dri-devel: < javierm> robclark: yeah, it's harder to re-enable it by mistake 15:24 #dri-devel: < robclark> right 15:24 #dri-devel: < MrCooper> llyyr: git bisect would probably be easiest to find what broke it for you 15:24 -!- fab [~fab@134.214.236.142] has joined #dri-devel 15:27 -!- dj-death [~djdeath@vps-8659ed31.vps.ovh.net] has joined #intel-3d 15:27 #intel-3d: < gfxstrand> dj-death: So, I still don't get what's going on with sliced 3D. 15:27 #intel-3d: < gfxstrand> Why do we have to change .Depth at all? 15:27 #intel-3d: < dj-death> gfxstrand: because of the query on the size 15:28 #intel-3d: < dj-death> otherwise you don't get the right answer from resinfo 15:28 #intel-3d: < gfxstrand> Oh 15:29 #intel-3d: < gfxstrand> That's not the answer I wanted to hear. :-( 15:30 #intel-3d: < dj-death> yeah sorry :( 15:30 #intel-3d: < dj-death> when themaister mentioned this wasn't even working well on DX driver, it didn't sound like a good start 15:30 -!- Deluxe [~Deluxe@78-80-27-182.customers.tmcz.cz] has joined #radeon 15:32 -!- urfu [~urfu@7YZAACPW4.tor-irc.dnsbl.oftc.net] has joined #radeon 15:34 #dri-devel: < jani> tzimmermann: Cc: intel-gfx, ensure it applies on top of drm-tip, that's all 15:34 -!- vliaskov_ [~vliaskov@dynamic-077-013-151-046.77.13.pool.telefonica.de] has joined #nouveau 15:34 -!- vliaskov_ [~vliaskov@dynamic-077-013-151-046.77.13.pool.telefonica.de] has joined #dri-devel 15:34 #intel-3d: < gfxstrand> Yeah, for SURFTYPE_3D, the docs says it returns (Depth+1)»LOD 15:34 #dri-devel: < jani> tzimmermann: in the more general case, if you post a series, also ensure you Cc the complete series 15:35 -!- lemonzest [~lemonzest@cpc86080-nott19-2-0-cust160.12-2.cable.virginm.net] has quit [Quit: WeeChat 3.6] 15:35 -!- lemonzest [~lemonzest@cpc86080-nott19-2-0-cust160.12-2.cable.virginm.net] has quit [Quit: WeeChat 3.6] 15:36 #intel-3d: < gfxstrand> I mean, I guess we could theoretically stick something in the descriptor memory 15:36 #intel-3d: < gfxstrand> We could also probably re-interpret 3D as 2D array unless it's Yf/Ys/64-tiled. 15:38 -!- vliaskov [~vliaskov@dynamic-077-188-078-191.77.188.pool.telefonica.de] has quit [Ping timeout: 480 seconds] 15:38 -!- vliaskov [~vliaskov@dynamic-077-188-078-191.77.188.pool.telefonica.de] has quit [Ping timeout: 480 seconds] 15:38 #intel-3d: < dj-death> don't know 15:38 #intel-3d: < dj-death> I also have a branch to do direct descriptors on DG2+ 15:39 #intel-3d: < dj-death> sticking more in descriptors is not going to be possible actually 15:39 #intel-3d: < dj-death> actually it's just not an option with EXT_descriptor_buffer 15:40 #intel-3d: < gfxstrand> So the >> LOD bothers me. 15:40 #intel-3d: < gfxstrand> Do the tests test anything other than LOD0? 15:40 #intel-3d: < gfxstrand> And test resinfo 15:40 #intel-3d: < dj-death> yes 15:41 #intel-3d: < dj-death> dEQP-VK.pipeline.monolithic.sliced_view_of_3d_image.mip_level.store.comp.level_1.offset_1_range_2 15:41 #intel-3d: < dj-death> if I remember correct it's an 8x8x8 image 15:41 #intel-3d: < gfxstrand> Ok, yeah, you adjust array_len 15:41 -!- vliaskov [~vliaskov@dynamic-078-054-192-023.78.54.pool.telefonica.de] has joined #nouveau 15:41 -!- vliaskov [~vliaskov@dynamic-078-054-192-023.78.54.pool.telefonica.de] has joined #dri-devel 15:42 #intel-3d: < gfxstrand> Why does Intel's sampler hardware have to suck so much?!? 15:42 #intel-3d: < gfxstrand> Oh, right, because the HW people are trying to innovate while implementing DX instead of just making something sane for SW to use. 15:43 #intel-3d: < gfxstrand> *sigh* 15:43 -!- vliaskov_ [~vliaskov@dynamic-077-013-151-046.77.13.pool.telefonica.de] has quit [Ping timeout: 480 seconds] 15:43 -!- vliaskov_ [~vliaskov@dynamic-077-013-151-046.77.13.pool.telefonica.de] has quit [Ping timeout: 480 seconds] 15:44 #intel-3d: < dj-death> the last 1.5 month of my life trying to find ways for EXT_descriptor_buffer 15:44 #intel-3d: < dj-death> I guess it was your last 5years 15:44 #intel-3d: < dj-death> in general 15:44 #freedesktop: < bentiss> sigh.... I think I'm giving up on the automation of approval for accounts: I spent a couple of days trying to think at the best architecture on how to have this, and I'd like to ideally have: a webhook handler that connects to issues on freedesktop/freedesktop, which requires an ack from any project maintainer, and then would automatically toggle the external status to internal 15:45 #intel-3d: < gfxstrand> *sigh* 15:45 #intel-3d: < gfxstrand> Same, same. 15:46 #intel-3d: < gfxstrand> When did I first start fighting with the sampler? Probably 2015 or so? *sigh* 15:46 #intel-3d: < gfxstrand> Anyway.... 15:46 #freedesktop: < bentiss> but... over the past few days we had something like 3 new actual users who needed code projects, and this would require me to have a solid rock brand new code to save what, a few seconds of my time? 15:46 #freedesktop: < bentiss> though if anybody wants to pick the ball, we can discuss it more :) 15:46 #intel-3d: < gfxstrand> I think I've convinced myself that what you're doing is fundamentally correct. 15:47 #intel-3d: < gfxstrand> Well, won't break things. I wouldn't call it correct. 😅 15:49 #intel-3d: < gfxstrand> I'm going to pull the branch and play with it. 15:49 #intel-3d: < dj-death> thanks a lot 15:52 -!- fxkamd [~Thunderbi@lnsm2-torontoxn-142-116-149-103.dsl.bell.ca] has joined #radeon 15:52 -!- fxkamd [~Thunderbi@lnsm2-torontoxn-142-116-149-103.dsl.bell.ca] has joined #dri-devel 15:52 -!- Deluxe [~Deluxe@78-80-27-182.customers.tmcz.cz] has quit [Ping timeout: 480 seconds] 15:52 -!- sparky4 [~sparky4@hutcheson-192.resnet.latech.edu] has joined #nouveau 15:53 -!- Tom^ [~tom@h-158-174-67-168.A159.priv.bahnhof.se] has quit [] 15:54 -!- bgs [~bgs@212-85-160-171.dynamic.telemach.net] has joined #dri-devel 15:57 -!- lemonzest [~lemonzest@cpc86080-nott19-2-0-cust160.12-2.cable.virginm.net] has joined #dri-devel 15:57 -!- lemonzest [~lemonzest@cpc86080-nott19-2-0-cust160.12-2.cable.virginm.net] has joined #radeon 16:00 #etnaviv: < cmeissl[m]> tomeu: In the mean time I just patched the platform to allow card1 to be used as the main device. This allows my compositor to use the client buffer for scan-out on both, the overlay and the primary plane. So at least I now know it technically should work. 16:03 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has joined #etnaviv 16:03 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has joined #dri-devel 16:03 -!- kzd [~kzd@static-198-54-130-84.cust.tzulo.com] has quit [Quit: kzd] 16:03 -!- kzd [~kzd@static-198-54-130-84.cust.tzulo.com] has quit [Quit: kzd] 16:04 -!- fab [~fab@134.214.236.142] has quit [Quit: fab] 16:04 -!- pallavim [~pallavim@134.134.137.87] has joined #intel-gfx 16:04 -!- pallavim [~pallavim@134.134.137.87] has joined #dri-devel 16:08 #etnaviv: < cmeissl[m]> But I saw something else today that I need to take a closer look. I am trying to use the 2D Core for composition and implemented some minimal example using the tests and examples from etnaviv to send commands to the gpu. At some point after running the example a few times it fails to allocate memory. I need to confirm, but it looks like allocating a gbm bo with SCANOUT and afterwards mapping it somehow leaks it. The map is unmapped and the 16:08 #etnaviv: < cmeissl[m]> bo is also cleaned up, but there is still a dmabuf active after exit. The dmabuf is attached to etnaviv. 16:10 -!- kzd [~kzd@static-198-54-130-84.cust.tzulo.com] has joined #radeon 16:10 -!- kzd [~kzd@static-198-54-130-84.cust.tzulo.com] has joined #dri-devel 16:11 -!- Duke`` [~plop@2a01cb0007977800d9e1421266e3bdbb.ipv6.abo.wanadoo.fr] has joined #dri-devel 16:11 -!- Duke`` [~plop@2a01cb0007977800d9e1421266e3bdbb.ipv6.abo.wanadoo.fr] has joined #intel-gfx 16:15 -!- jarthur [~jarthur@cpe-70-114-194-101.austin.res.rr.com] has joined #freedesktop 16:15 -!- heat [~heat@0002b861.user.oftc.net] has quit [Read error: Connection reset by peer] 16:15 -!- heat [~heat@0002b861.user.oftc.net] has quit [Read error: Connection reset by peer] 16:15 -!- heat [~heat@0002b861.user.oftc.net] has quit [Read error: Connection reset by peer] 16:16 -!- jarthur [~jarthur@cpe-70-114-194-101.austin.res.rr.com] has joined #radeon 16:16 -!- heat [~heat@0002b861.user.oftc.net] has joined #intel-3d 16:16 -!- heat [~heat@0002b861.user.oftc.net] has joined #intel-gfx 16:16 -!- heat [~heat@0002b861.user.oftc.net] has joined #dri-devel 16:17 #wayland: < wlb> wayland/main: Simon Ser * build: bump version to 1.21.91 for the alpha release https://gitlab.freedesktop.org/wayland/wayland/commit/344d31f871e7 meson.build 16:17 #wayland: < wlb> wayland New tag: 1.21.91 https://gitlab.freedesktop.org/wayland/wayland/tags/1.21.91 16:20 -!- aravind [~aravind@134.134.137.85] has quit [Ping timeout: 480 seconds] 16:20 -!- aravind [~aravind@134.134.137.85] has quit [Ping timeout: 480 seconds] 16:21 -!- Tom^ [~tom@h-158-174-67-168.A159.priv.bahnhof.se] has joined #nouveau 16:28 -!- vkareh [~vkareh@00026f70.user.oftc.net] has quit [Quit: WeeChat 3.6] 16:28 #wayland: < wlb> wayland.freedesktop.org/main: Simon Ser * releases: add Wayland 1.21.91 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/cf92f7f78c1b releases.html 16:28 -!- vkareh [~vkareh@00026f70.user.oftc.net] has joined #freedesktop 16:29 -!- mowcat [~mowcat@host81-155-196-87.range81-155.btcentralplus.com] has joined #radeon 16:29 #etnaviv: < cmeissl[m]> maybe, it seems that calling gbm_bo_map creates it internally 16:29 -!- Duke`` [~plop@2a01cb0007977800d9e1421266e3bdbb.ipv6.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 16:29 -!- Duke`` [~plop@2a01cb0007977800d9e1421266e3bdbb.ipv6.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 16:31 -!- vkareh [~vkareh@00026f70.user.oftc.net] has quit [] 16:31 -!- vkareh [~vkareh@00026f70.user.oftc.net] has joined #freedesktop 16:32 #etnaviv: < cmeissl[m]> is it possible it references itself and therefore it doesn't get cleaned up when calling gbm_bo_destroy? 16:33 -!- otavio__ [~otavio@200-203-24-19.user3p.brasiltelecom.net.br] has quit [Remote host closed the connection] 16:33 -!- vkareh [~vkareh@00026f70.user.oftc.net] has quit [] 16:33 -!- vkareh [~vkareh@00026f70.user.oftc.net] has joined #freedesktop 16:33 -!- Tom^ [~tom@h-158-174-67-168.A159.priv.bahnhof.se] has quit [] 16:34 -!- vkareh [~vkareh@00026f70.user.oftc.net] has quit [] 16:34 -!- vkareh [~vkareh@00026f70.user.oftc.net] has joined #freedesktop 16:35 -!- mowcat [~mowcat@host81-155-196-87.range81-155.btcentralplus.com] has quit [Remote host closed the connection] 16:37 -!- mowcat [~mowcat@host81-155-196-87.range81-155.btcentralplus.com] has joined #radeon 16:38 -!- Duke`` [~plop@lfbn-idf1-1-2098-241.w90-127.abo.wanadoo.fr] has joined #dri-devel 16:38 -!- Duke`` [~plop@lfbn-idf1-1-2098-241.w90-127.abo.wanadoo.fr] has joined #intel-gfx 16:41 -!- otavio_ [~otavio@200-203-24-19.user3p.brasiltelecom.net.br] has joined #etnaviv 16:43 -!- fab [~fab@bellet.info] has joined #dri-devel 16:44 -!- floof58 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has quit [Read error: Connection reset by peer] 16:44 -!- floof58 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has quit [Read error: Connection reset by peer] 16:45 -!- floof58 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has joined #radeon 16:45 -!- floof58 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has joined #wayland 16:45 -!- gtristan [~tristan@223.38.36.71] has quit [Ping timeout: 480 seconds] 16:46 -!- BCMM [~BCMM@00026736.user.oftc.net] has quit [Quit: Konversation terminated!] 16:50 -!- fxkamd [~Thunderbi@lnsm2-torontoxn-142-116-149-103.dsl.bell.ca] has quit [] 16:50 -!- fxkamd [~Thunderbi@lnsm2-torontoxn-142-116-149-103.dsl.bell.ca] has quit [] 16:50 -!- XYZ89 [~XYZ@37-48-42-64.nat.epc.tmcz.cz] has quit [Read error: Connection reset by peer] 16:53 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Quit: Leaving] 16:53 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Quit: Leaving] 16:55 -!- mmu_man [~revol@82-65-227-82.subs.proxad.net] has quit [Ping timeout: 480 seconds] 16:56 -!- drod [~ldm@ip-95-220-105-14.bb.netbynet.ru] has joined #lima 17:05 -!- XYZ [~XYZ@37-48-42-64.nat.epc.tmcz.cz] has joined #radeon 17:05 -!- sknebel_ [~quassel@v22016013254630973.happysrv.de] has quit [] 17:05 -!- sknebel [~quassel@v22016013254630973.happysrv.de] has joined #etnaviv 17:06 -!- mmu_man [~revol@188410969.box.freepro.com] has joined #nouveau 17:07 -!- molinari [~molinari@176-151-233-216.abo.bbox.fr] has quit [Ping timeout: 480 seconds] 17:14 -!- sarnex [~sarnex@0002ba23.user.oftc.net] has quit [Quit: Quit] 17:14 -!- sarnex [~sarnex@0002ba23.user.oftc.net] has quit [Quit: Quit] 17:14 -!- sarnex [~sarnex@0002ba23.user.oftc.net] has quit [Quit: Quit] 17:14 -!- sarnex [~sarnex@075-130-228-226.res.spectrum.com] has joined #d3d9 17:14 -!- sarnex [~sarnex@075-130-228-226.res.spectrum.com] has joined #dri-devel 17:14 -!- sarnex [~sarnex@075-130-228-226.res.spectrum.com] has joined #radeon 17:15 -!- sgruszka [~sgruszka@134.191.220.85] has quit [Remote host closed the connection] 17:15 -!- smiles [~smiles@2409:8a00:db0:5800:c76:ca8d:a1a:d77b] has quit [Ping timeout: 480 seconds] 17:15 -!- gawin [~filip@0002cee1.user.oftc.net] has quit [Ping timeout: 480 seconds] 17:15 #wayland: < wlb> weston/main: Alexandros Frantzis * xwayland: Handle shell hint for client to choose dimensions https://gitlab.freedesktop.org/wayland/weston/commit/2acd2c74891c xwayland/window-manager.c 17:15 #wayland: < wlb> weston Issue #722 closed \o/ (Resize is broken for X windows https://gitlab.freedesktop.org/wayland/weston/-/issues/722) 17:15 #wayland: < wlb> weston Merge request !1180 merged \o/ (xwayland: Handle shell hint for client to choose dimensions https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1180) 17:17 -!- Mary6 [~Mary@2a01:4f9:6b:22d0::3] has quit [] 17:18 -!- Mary6 [~Mary@2a01:4f9:6b:22d0::3] has joined #nouveau 17:19 -!- Mary6 [~Mary@2a01:4f9:6b:22d0::3] has quit [] 17:19 -!- Mary [~Mary@2a01:4f9:6b:22d0::3] has joined #nouveau 17:20 #intel-3d: < gfxstrand> dj-death: Ok, I've got an alternate branch which I think is cleaner and more in line with how I intended the ISL interface to work. However, it needs a blorp fix and I have no clue what that blorp fix will break so we're running it through CI. :D 17:20 #freedesktop: < anholt_> bentiss: I suspect that "latency to account activation" is the most important thing to users -- any way other responsible admin-ish (but not wanting to be real admins) folks could help? 17:24 -!- jkrzyszt [~jkrzyszt@134.191.221.86] has quit [Ping timeout: 480 seconds] 17:24 -!- jkrzyszt [~jkrzyszt@134.191.221.86] has quit [Ping timeout: 480 seconds] 17:27 -!- tzimmermann [~tzimmerma@2001:9e8:21d0:f200:f72:4873:8276:a047] has quit [Quit: Leaving] 17:27 -!- tzimmermann [~tzimmerma@2001:9e8:21d0:f200:f72:4873:8276:a047] has quit [Quit: Leaving] 17:27 -!- tzimmermann [~tzimmerma@2001:9e8:21d0:f200:f72:4873:8276:a047] has quit [Quit: Leaving] 17:27 -!- tzimmermann [~tzimmerma@2001:9e8:21d0:f200:f72:4873:8276:a047] has quit [Quit: Leaving] 17:27 -!- tzimmermann [~tzimmerma@2001:9e8:21d0:f200:f72:4873:8276:a047] has quit [Quit: Leaving] 17:29 -!- manuel_ [~manuel198@62.99.131.178] has quit [] 17:35 -!- urfu [~urfu@7YZAACPW4.tor-irc.dnsbl.oftc.net] has quit [] 17:35 -!- jmdaemon [~jmdaemon@0002d6bd.user.oftc.net] has joined #wayland 17:37 -!- digetx [~quassel@109.252.117.89] has quit [Ping timeout: 480 seconds] 17:37 -!- digetx [~quassel@109.252.117.89] has quit [Ping timeout: 480 seconds] 17:37 -!- MajorBiscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has quit [Quit: WeeChat 3.6] 17:37 -!- MajorBiscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has quit [Quit: WeeChat 3.6] 17:37 -!- MajorBiscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has quit [Quit: WeeChat 3.6] 17:37 -!- MajorBiscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has quit [Quit: WeeChat 3.6] 17:37 -!- MajorBiscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has quit [Quit: WeeChat 3.6] 17:37 -!- MajorBiscuit [~MajorBisc@c-001-024-033.client.tudelft.eduvpn.nl] has quit [Quit: WeeChat 3.6] 17:39 #dri-devel: < marex> mripard: let's see what happens now 17:42 -!- gtristan [~tristan@223.38.36.71] has joined #freedesktop 17:43 -!- digetx [~quassel@109-252-117-89.nat.spd-mgts.ru] has joined #freedreno 17:43 -!- digetx [~quassel@109-252-117-89.nat.spd-mgts.ru] has joined #dri-devel 17:47 #freedesktop: < bentiss> anholt_: well, either we go with the full manual: when a freedesktop/freedesktop issue is created from an external user, we edit the user to make him/her internal, either someone writes a small program/bot that does exactly that based on some rules to be defined 17:47 -!- macromorgan [~macromorg@76.244.6.13] has quit [Quit: Leaving] 17:48 #freedesktop: < bentiss> basically I do not think we want an automated "user created an issue -> user got rights", but something more like "user created issue and request right -> a human review (being any maintainer, not just admins -> tag the issue (or assign to a bot, or use a quick action like /ack) -> the bot grants privileges to the user" 17:49 #freedreno: < abhinav__> robclark agree with you and like I have mentioned earlier, QC plans to leverage and enhance the gitlab CI for more chips, just need a little bit of time as team has been busy 17:49 #freedesktop: < bentiss> ideally I'd like a followup on the users we granted privileges, but that might just as well be sufficient to make the platform hostile to such spam as they need an extra step for us 17:51 #freedesktop: < bentiss> but just to be clear, that's my current idea, and I'm open to other suggestions. I even wondered if we could not have free for all projects for external users so they would not even have to fork, but that requires project participation and is probably not the best :) 17:51 #freedesktop: * bentiss is going to be afk for the evening 17:57 -!- xyene [~xyene@osmium.quantum2.xyz] has quit [Quit: ZNC - https://znc.in] 17:57 -!- xyene [~xyene@osmium.quantum2.xyz] has joined #wayland 17:59 -!- gtristan [~tristan@223.38.36.71] has quit [Ping timeout: 480 seconds] 17:59 -!- nchery [~nchery@134.134.139.84] has joined #intel-gfx 17:59 -!- nchery [~nchery@134.134.139.84] has joined #intel-3d 17:59 -!- nchery [~nchery@134.134.139.84] has joined #dri-devel 17:59 #dri-devel: < karolherbst> uhm.. llvmpipe uses 32 bit pointers when doing a 32 bit build, right? 18:00 -!- Moprius [~Thunderbi@189.40.86.205] has joined #radeon 18:00 -!- Moprius [~Thunderbi@189.40.86.205] has joined #wayland 18:02 #dri-devel: < airlied> if a tree falls in the woods... 18:04 #dri-devel: < HdkR> One would hope so 18:04 #dri-devel: < karolherbst> yeah.. just noticed today, that llvmpipe always claims to be 64 bits, so CL is probably broken in 32 bit applications :) 18:05 #dri-devel: < airlied> if a tree falls in the woods... 18:05 #dri-devel: < airlied> :-P 18:05 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has quit [Ping timeout: 480 seconds] 18:05 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has quit [Ping timeout: 480 seconds] 18:05 #dri-devel: < airlied> I wonder where you'd find a 32-bit CL program in the wild 18:05 #dri-devel: < karolherbst> wine 18:06 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has quit [Ping timeout: 480 seconds] 18:06 #dri-devel: < karolherbst> but also apparently somebody uses it on a 32 bit host... 18:06 #dri-devel: < airlied> for wine wouldn't it need an application to use it? 18:06 #dri-devel: < karolherbst> sure 18:06 #dri-devel: < karolherbst> already got bugs like that 18:06 #dri-devel: < airlied> I wonder where you'd find a 32-bit CL program in the wild 18:06 #dri-devel: < airlied> for Windows 18:06 -!- gawin [~filip@0002cee1.user.oftc.net] has joined #dri-devel 18:06 #dri-devel: < karolherbst> yeah 18:06 #dri-devel: < karolherbst> I fixed a bug recently for that 18:07 #dri-devel: < airlied> but maybe there are a bunch 18:07 #dri-devel: < karolherbst> it's windows 18:07 #dri-devel: < karolherbst> applications were 32 bit only for a looong time 18:08 #freedesktop: < anholt_> bentiss: I guess I was trying to get at: if you're leaning toward manual because the load isn't big enough to justify writing a bot, how do others help share the load? 18:08 #dri-devel: < airlied> yeah I'm just more surprised there's any CL apps 18:08 #dri-devel: < karolherbst> airlied: https://github.com/gchudov/cuetools.net this what a user filed a bug with 18:09 #dri-devel: < karolherbst> and the release archives only contain 32 bit versions 18:09 #dri-devel: < karolherbst> not sure you can even build it as 64 bit 18:10 #dri-devel: < karolherbst> anyway.. that bug wasn't 32 bit specific.. but the llvmpipe one is :) 18:12 -!- XYZ [~XYZ@37-48-42-64.nat.epc.tmcz.cz] has quit [Ping timeout: 480 seconds] 18:15 #dri-devel: < airlied> karolherbst: PIPE_CAP_COMPUTE_ADDRESS_BITS? 18:15 #dri-devel: < karolherbst> yeah 18:15 #dri-devel: < airlied> COMPUTE_CAP_ADDRESS_BITS evn 18:15 #intel-3d: < gfxstrand> Woo! GRL kernels are finding bugs. :D 18:16 #dri-devel: < karolherbst> anyway, that needs to return the bits of the host machine I guess 18:16 #freedesktop: < mupuf> I dont dislike needing an internal user ack the external one 18:16 #dri-devel: < karolherbst> currently checking if that's the only issue 18:17 #dri-devel: < airlied> just change it to sizeof(void*) * 8 18:17 #dri-devel: < karolherbst> but rusticl should be able to run a 64 bit GPU on a 32 bit host.. so maybe something funky is going on 18:17 #freedesktop: < mupuf> Maybe the internal user needs to be at least 6 months old or something 18:18 #dri-devel: < airlied> karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21601 18:22 -!- XYZ [~XYZ@89-24-56-234.nat.epc.tmcz.cz] has joined #radeon 18:22 -!- Moprius [~Thunderbi@0002e253.user.oftc.net] has quit [Read error: Connection reset by peer] 18:22 -!- Moprius [~Thunderbi@0002e253.user.oftc.net] has quit [Read error: Connection reset by peer] 18:23 -!- drod [~ldm@ip-95-220-105-14.bb.netbynet.ru] has quit [Ping timeout: 480 seconds] 18:26 -!- lynxeye [~lynxeye@2a02:560:58ef:c500:20e1:7881:a58b:630d] has quit [Quit: Leaving.] 18:26 -!- lynxeye [~lynxeye@2a02:560:58ef:c500:20e1:7881:a58b:630d] has quit [Quit: Leaving.] 18:27 #freedesktop: < daniels> mupuf: admin mode - go for it 18:27 #freedesktop: < mupuf> Ack 18:27 #freedesktop: < daniels> bentiss: I’m also out btw, am on hols today 18:28 #freedesktop: < daniels> anholt_: I believe you’re already an admin so can approve new accounts? 18:30 -!- drod [~ldm@ip-95-220-105-14.bb.netbynet.ru] has joined #lima 18:31 #intel-3d: < dj-death> got a ton of unexpected failures 18:31 #intel-3d: < dj-death> I wonder if it's it's your change ;) 18:31 #freedesktop: < anholt_> daniels: does a wiki tell me how to? ;) 18:31 #dri-devel: < karolherbst> oh yeah.. I see a few fails :) 18:31 #intel-3d: < gfxstrand> with GRL? 18:31 #dri-devel: < karolherbst> let's see what's going on there 18:31 #intel-3d: < gfxstrand> Oh, it found other bugs and I haven't landed those changes yet. 18:32 #intel-3d: < gfxstrand> But it's also possible I broke GRL with the first version of the bit size reworks 18:34 #freedesktop: < anholt_> added a notification for myself for the issues, which I apparently have not been monitoring 18:34 #nouveau: < fdobridge> @gfxstrand @karolherbst🐧 so with GSP enabled, the context gets killed when we submit the initial context draw state pushbuf at least on turing 18:34 #nouveau: < fdobridge> what does it complain about? 18:34 #nouveau: < fdobridge> GSP says you are dead 18:35 #nouveau: < fdobridge> I know nothing more 18:35 #intel-3d: < gfxstrand> CL exercises all that stuff a lot harder than GL or Vulkan 18:35 #nouveau: < fdobridge> well.. then I can't really help here either 18:35 #nouveau: < fdobridge> the wonders of firmware 😛 18:35 #nouveau: < fdobridge> though 18:35 #nouveau: < fdobridge> I suspect it might be related to the channel binding 18:35 #nouveau: < fdobridge> but... 18:35 #nouveau: < fdobridge> GL works fine 18:35 #nouveau: < fdobridge> in any case 18:35 #nouveau: < fdobridge> we need errors 18:35 #nouveau: < fdobridge> if we don't get errors, we can't use GSP 18:36 #nouveau: < fdobridge> @airlied you could dump the buffer and see if there is anything obviously wrong 18:36 #nouveau: < fdobridge> but... 18:37 #nouveau: < fdobridge> I don't like guessing and I don't think we are doing anything crazy in nvk here 18:37 -!- nchery [~nchery@134.134.139.84] has quit [Quit: Leaving] 18:37 -!- nchery [~nchery@134.134.139.84] has quit [Quit: Leaving] 18:37 -!- nchery [~nchery@134.134.139.84] has quit [Quit: Leaving] 18:37 #nouveau: < fdobridge> I assume at some point we can process better errors, I'd hope so 18:37 #nouveau: < fdobridge> we should make that a requirement 18:37 #nouveau: < fdobridge> I'm mostly done guessing what nvidia's firmware is up to 18:37 #intel-3d: < dj-death> gfxstrand: I thought I ran your change with CI on DG2 and RT enabled 18:38 #intel-3d: < dj-death> first iteration was probably fine 18:38 #intel-3d: < dj-death> it's the second MR right? 18:38 #intel-3d: < gfxstrand> dj-death: Yeah, I just fixed a bug with it today 18:42 -!- Deluxe [~Deluxe@212.4.150.151] has joined #radeon 18:43 #freedesktop: < daniels> anholt_: go to the user profile, click on the silhouette icon which takes you to the admin section for that user, press edit, change type from internal to external 18:45 #dri-devel: < karolherbst> nice.. it's image arguments which are broken 18:45 #freedesktop: < anholt_> sounds good 18:50 -!- ximion1 [~ximion@2a02:8071:a8a:3a20::7093] has joined #freedesktop 18:51 #freedesktop: < alanc> another batch of spam has come in: https://gitlab.freedesktop.org/search?scope=issues&search=stream 18:52 -!- ximion [~ximion@ip-176-199-211-108.um44.pools.vodafone-ip.de] has quit [Ping timeout: 480 seconds] 18:54 #nouveau: < fdobridge> appears to be sw.cls init 18:55 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #dri-devel 18:55 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #wayland 18:55 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #radeon 19:00 #wayland: < emersion> pq, fyi: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4563201f33a022fc0353033d9dfeb1606a88330 19:01 #wayland: < emersion> (you were asking about this a while back) 19:01 -!- mvlad [~mvlad@2a02:2f08:4c03:f700:7656:3cff:fe3f:7ce9] has quit [Remote host closed the connection] 19:01 -!- mvlad [~mvlad@2a02:2f08:4c03:f700:7656:3cff:fe3f:7ce9] has quit [Remote host closed the connection] 19:01 -!- mvlad [~mvlad@2a02:2f08:4c03:f700:7656:3cff:fe3f:7ce9] has quit [Remote host closed the connection] 19:01 -!- mvlad [~mvlad@2a02:2f08:4c03:f700:7656:3cff:fe3f:7ce9] has quit [Remote host closed the connection] 19:04 #nouveau: < fdobridge> ah nvc0 has if (dev->chipset < 0x140) { 19:12 #nouveau: < fdobridge> okay 189 works around it for now for me 19:18 -!- djbw [~djbw@fmdmzpr02-ext.fm.intel.com] has joined #dri-devel 19:18 -!- dwlsalmeida4 [~dwlsalmei@gyros.collabora.co.uk] has quit [] 19:18 -!- gawin [~filip@0002cee1.user.oftc.net] has quit [Ping timeout: 480 seconds] 19:19 -!- dwlsalmeida [~dwlsalmei@gyros.collabora.co.uk] has joined #dri-devel 19:21 #nouveau: < fdobridge> That's believable 19:22 -!- rasterman [~rasterman@cpc99584-brnt1-2-0-cust1380.4-2.cable.virginm.net] has quit [Quit: Gettin' stinky!] 19:22 -!- rasterman [~rasterman@cpc99584-brnt1-2-0-cust1380.4-2.cable.virginm.net] has quit [Quit: Gettin' stinky!] 19:23 #nouveau: < fdobridge> back to having broken sync now, which is what I wanted to dig into 😛 19:24 #dri-devel: < dwlsalmeida> airlied Lynne Hey there, I am trying to cook up some initial vulkan video vp9 support in Mesa following along your footsteps. I have an AMD box which I can test through RADV. Do any of you have any documentation on the firmware interface? I am taking cues from radeonsi, but sometimes I miss a more unambiguous source. 19:25 #nouveau: < fdobridge> ahh yeah.. that would do it 19:25 -!- ybogdano is now known as Guest6190 19:25 -!- ybogdano is now known as Guest6190 19:25 -!- ybogdano is now known as Guest6190 19:25 -!- ybogdano is now known as Guest6190 19:25 -!- ybogdano is now known as Guest6190 19:25 -!- ybogdano [~ybogdano@134.134.139.85] has joined #freedesktop 19:25 -!- ybogdano [~ybogdano@134.134.139.85] has joined #intel-gfx 19:25 -!- ybogdano [~ybogdano@134.134.139.85] has joined #intel-3d 19:25 -!- ybogdano [~ybogdano@134.134.139.85] has joined #dri-devel 19:25 -!- ybogdano [~ybogdano@134.134.139.85] has joined #wayland 19:25 #nouveau: < fdobridge> ohh.. we should ask nvidia if they can give us doc on all those fancy sw methods 19:25 #dri-devel: < airlied> dwlsalmeida: no the radeonsi interface is all the info available 19:27 -!- macromorgan [~macromorg@76.244.6.13] has joined #dri-devel 19:27 #dri-devel: < airlied> dwlsalmeida: the interface is usually sane until you have to work out how references work 19:28 #dri-devel: < dwlsalmeida> airlied I noticed this was a problem with AV1 as well, IIRC? something about it being hard to uniquely identify a frame 19:28 #dri-devel: < dwlsalmeida> in v4l2 there's timestamps, so that was easy over there 19:29 #dri-devel: < airlied> yeah the fw appears to write some frame indexes into the context buffers, and gets upset when they are different 19:30 #dri-devel: < airlied> it was also a bit painful for h264, but more around how vulkan DPB mgmt is explicit 19:30 #dri-devel: < airlied> I thought av1 was the same problem, but it was slightly different 19:31 #dri-devel: < marex> mripard: hey, so, I spent a while communicating with jagan_ now and I think there is a cyclic dependency between DSIM probe and DSI83 bridge probe 19:33 #dri-devel: < marex> mripard: basically, since https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/bridge/ti-sn65dsi83.c?id=6ef7ee48765fa3067858d11ecdf3acbc7c19df80 , sn65dsi83_host_attach() called from dsi83 i2c bridge driver .probe callback requires dsi_host to be available , at its .probe time 19:33 #dri-devel: < marex> mripard: if no dsi_host available, DSI83 does -EPROBE_DEFER and that's the end 19:34 #dri-devel: < dwlsalmeida> airlied Btw this confuses me -> void *render_pic_list[32]; 19:34 #dri-devel: < dwlsalmeida> I assume this comes from h264 (i.e. 16 x 2 fields), and just carries over to the other codecs? because VP9 only has up to 8 frames as references at a time 19:34 #dri-devel: < dwlsalmeida> Also would you mind a quick review once this progresses a bit more? I can open up a MR same as you did 19:34 #dri-devel: < marex> mripard: at the same time, if DSIM bridge/host attemps to look up bridge in its .probe() callback, it fails with EPROBE_DEFER too, because the bridge driver didn't probe yet 19:34 #dri-devel: < marex> mripard: so, there is a cyclic dependency between DSIM host and DSI83 bridge , since they both depend on each other at .probe() time 19:35 #dri-devel: < marex> mripard: it seems that is why jagan was going on about the .attach time bridge look up all the time 19:35 #dri-devel: < DemiMarie> airlied: totally undocumented firmware interface? That sucks. 19:35 -!- Szadek [~Szadek@194.36.25.10] has quit [Quit: WeeChat 3.8] 19:35 #dri-devel: < DemiMarie> I wonder if anyone has tried fuzzing the firmware. 19:37 #dri-devel: < DemiMarie> marmarek: this kind of stuff is why I am nervous about GPU security 19:37 -!- Szadek [~Szadek@185.213.155.160] has joined #wayland 19:37 #dri-devel: < airlied> dwlsalmeida: render_pic_list is a vaapi ism anyways 19:37 #dri-devel: < airlied> but yes it's sized for h264 19:44 #nouveau: < fdobridge> Yeah, that'd be nice if they have SW methods 19:44 #nouveau: < fdobridge> Particularly, we need to make sure that we don't break the helper pixels fix 19:44 #nouveau: < fdobridge> @gfxstrand do you see any PBDMA errors in your dmesg at all? 19:45 #dri-devel: < dwlsalmeida> airlied do you happen to remember where this number comes from? -> #define RDECODE_VP9_PROBS_DATA_SIZE 2304 19:45 #dri-devel: < dwlsalmeida> The actual probability table is 2040 bytes long 19:45 #nouveau: < fdobridge> I've seen those and I think it's caused by that fix, so we might need to reconsider how it works anyways, I've no idea what GSP does here 19:45 #nouveau: < fdobridge> Yup, piles 19:45 #dri-devel: < dwlsalmeida> I do vaguely remember this number 2304 from somewhere though ... 19:45 #nouveau: < fdobridge> yeah try commenting out the sw.cls and see do they go away 19:46 #nouveau: < fdobridge> you remember this magic thing nvidia did where they allow userspace to set certain registers? 19:46 #nouveau: < fdobridge> via macros and stuff 19:46 #nouveau: < fdobridge> I suspect we need to do the same thing to be compatible to GSP 19:46 #nouveau: < fdobridge> Probably 19:46 #nouveau: < fdobridge> We just need to know how that magic works 19:46 #nouveau: < fdobridge> and nvidia probably has to set up a buffer with bit masks of those regs 19:46 #nouveau: < fdobridge> and nouveau probably has to set up a buffer with bit masks of those regs (edited) 19:46 #nouveau: < fdobridge> I checked how they did it in nvgpu 19:47 #nouveau: < fdobridge> I should check how they do it in their open driver 19:47 #nouveau: < fdobridge> Yeah 19:47 #nouveau: < fdobridge> anyway, if anybody throws me a branch with all the GSP stuff I can look into it, as I was planning to upstream those bits anyway 19:47 #nouveau: < fdobridge> The other option is if we can just have nouveau.ko do some stuff to the context at context creation. 19:47 #nouveau: < fdobridge> I don't think you need GSP though, I think we already generate PBDMA errors 19:47 #nouveau: < fdobridge> we just don't blow away the context as aggressively 19:48 #nouveau: < fdobridge> that's not the problem 19:48 #nouveau: < fdobridge> the core issue is, there are registers we have to mess with from userspace 19:48 #nouveau: < fdobridge> it's not like GSP is seeing the pushbuf here, it's just reporting the hw error 19:48 #nouveau: < fdobridge> right 19:48 #nouveau: < fdobridge> but that will cause regressions in nvk if we don't do it 19:49 #nouveau: < fdobridge> so we have to figure out how to do the same thing with GSP 19:49 #nouveau: < fdobridge> yes well we should also figure out how to do it without GSP 19:49 #nouveau: < fdobridge> there is a magic context switch mmio register with a bit which enables/disables memory load in helper invcations 19:49 #nouveau: < fdobridge> it's disabled by default 19:49 #nouveau: < fdobridge> we have to enable it 19:49 #nouveau: < fdobridge> we already do it without GSP 🙂 19:49 -!- iive [~iive@85.187.76.102] has joined #dri-devel 19:49 -!- iive [~iive@85.187.76.102] has joined #radeon 19:49 -!- iive [~iive@85.187.76.102] has joined #d3d9 19:49 #nouveau: < fdobridge> but before we upstream it, we should see how it works with GSP so it looks the same 19:49 #nouveau: < fdobridge> no we don't do it 19:50 #nouveau: < fdobridge> we do it, but it seems to blow up in places 19:50 #nouveau: < fdobridge> ..... 19:50 #nouveau: < fdobridge> hence all those PBDMA errors 19:50 #nouveau: < fdobridge> please understand what I'm writing 19:51 -!- AbleBacon [~AbleBacon@136.35.133.35] has joined #freedesktop 19:51 #nouveau: < fdobridge> I have a patch to do it via the sw stuff 19:51 #nouveau: < fdobridge> that isn't upstream yet 19:51 #nouveau: < fdobridge> before upstreaming it, we should see what GSP is doing 19:51 #nouveau: < fdobridge> and implement it the same way prior GSP 19:52 #nouveau: < fdobridge> I've no idea though how to work out what the GSP interface is for it 19:52 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has joined #etnaviv 19:52 -!- JohnnyonFlame [~quassel@189-84-176-198.zamix.com.br] has joined #dri-devel 19:52 -!- Zopolis4 [uid504804@id-504804.ilkley.irccloud.com] has joined #dri-devel 19:52 #nouveau: < fdobridge> did nvidia ever drop any useful hints on how their userspace programs the workaround? 19:53 #nouveau: < fdobridge> via macros 19:53 #nouveau: < fdobridge> they interrupt the firmware 19:54 #nouveau: < fdobridge> I had a dump of all their macros at one point 19:54 #nouveau: < fdobridge> or rather.. use a doorbell or something. Anyway, nvgpu is setting up a buffer 19:54 #nouveau: < fdobridge> and each bit represents a mmio reg 19:54 #nouveau: < fdobridge> and the buffer decides what userspace can mess with 19:54 #nouveau: < fdobridge> and when bootstrapping the firmware, they pass that buffer along 19:54 #nouveau: < fdobridge> and there are like 20? slots for doing random interactions wiht the firmware afaik 19:54 #nouveau: < fdobridge> and there are like 20? slots for doing random interactions with the firmware afaik (edited) 19:57 -!- mmu_man [~revol@188410969.box.freepro.com] has quit [Ping timeout: 480 seconds] 20:03 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 20:03 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 20:03 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 20:03 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 20:03 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 20:04 -!- Supersaiyan_IV [~QAM@ua-85-228-153-205.bbcust.telenor.se] has joined #intel-gfx 20:04 -!- Supersaiyan_IV [~QAM@ua-85-228-153-205.bbcust.telenor.se] has joined #radeon 20:08 #dri-devel: < airlied> dwlsalmeida: is it sizeof struct rvcn_dec_vp9_probs_s ? 20:11 -!- mmu_man [~revol@82-65-227-82.subs.proxad.net] has joined #nouveau 20:11 -!- gawin [~filip@0002cee1.user.oftc.net] has joined #dri-devel 20:16 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has joined #dri-devel 20:21 #dri-devel: < karolherbst> airlied: seems like your llvmpipe pointer fix actually breaks 32 bit stuff now 20:21 #dri-devel: < karolherbst> https://gist.githubusercontent.com/karolherbst/fd278ba287ca2a3d945eb180d63835ab/raw/dddfa26d4e983bb5f04462fda3ec589898e8bf22/gistfile1.txt 20:22 #dri-devel: < karolherbst> uhh.. maybe there are just more bugs around somewhere... 20:22 -!- ocrete [~tester@test02-cl-test-nbg-hz.collaboradmins.com] has joined #freedesktop 20:23 #dri-devel: < mareko> tarceri: what does gl_nir_link_glsl/spirv need nir_link_opt_varyings for? can we move it after gl_nir_link_glsl/spirv? 20:24 -!- gawin [~filip@0002cee1.user.oftc.net] has quit [Ping timeout: 480 seconds] 20:25 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 20:25 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 20:25 -!- junaid [~Junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 20:28 #dri-devel: < agd5f> DemiMarie, if you have specific questions we can ask the firmware teams. 20:29 -!- Jeremy_Rand_Talos_ [~Jeremy_Ra@4G4AAC2CK.tor-irc.dnsbl.oftc.net] has joined #dri-devel 20:30 -!- Jeremy_Rand_Talos [~Jeremy_Ra@7YZAACPCV.tor-irc.dnsbl.oftc.net] has quit [Remote host closed the connection] 20:30 #dri-devel: < agd5f> er dwlsalmeida ^^ 20:30 -!- ybogdano [~ybogdano@134.134.139.85] has joined #freedesktop 20:31 -!- ybogdano [~ybogdano@134.134.139.85] has joined #intel-gfx 20:31 -!- ybogdano [~ybogdano@134.134.139.85] has joined #intel-3d 20:31 -!- ybogdano [~ybogdano@134.134.139.85] has joined #dri-devel 20:31 -!- ybogdano [~ybogdano@134.134.139.85] has joined #wayland 20:34 -!- Tom^ [~tom@h-158-174-67-168.A159.priv.bahnhof.se] has joined #nouveau 20:41 -!- hogander [~jhogande@134.191.220.83] has quit [] 20:43 -!- ocrete [~tester@test02-cl-test-nbg-hz.collaboradmins.com] has quit [Quit: The Lounge - https://thelounge.chat] 20:43 -!- vkareh is now known as Guest6195 20:43 -!- vkareh [~vkareh@00026f70.user.oftc.net] has joined #freedesktop 20:44 -!- vkareh [~vkareh@00026f70.user.oftc.net] has quit [] 20:45 -!- vkareh [~vkareh@00026f70.user.oftc.net] has joined #freedesktop 20:46 -!- vkareh [~vkareh@00026f70.user.oftc.net] has quit [] 20:51 -!- kts [~kts@103.73.236.54] has quit [Quit: Konversation terminated!] 20:51 -!- kts [~kts@103.73.236.54] has quit [Quit: Konversation terminated!] 20:51 -!- kts [~kts@103.73.236.54] has quit [Quit: Konversation terminated!] 20:51 -!- kts [~kts@103.73.236.54] has quit [Quit: Konversation terminated!] 20:59 -!- gallo72 [~gallo@test02-cl-test-nbg-hz.collaboradmins.com] has joined #dri-devel 20:59 -!- gallo72 [~gallo@test02-cl-test-nbg-hz.collaboradmins.com] has joined #freedesktop 20:59 -!- gallo72 [~gallo@test02-cl-test-nbg-hz.collaboradmins.com] has joined #lima 21:02 -!- stuart [~jssummer@192.55.54.51] has joined #intel-gfx 21:02 -!- stuart [~jssummer@192.55.54.51] has joined #dri-devel 21:04 -!- nchery [~nchery@50.39.99.32] has joined #intel-gfx 21:04 -!- nchery [~nchery@50.39.99.32] has joined #intel-3d 21:04 -!- nchery [~nchery@50.39.99.32] has joined #dri-devel 21:04 -!- dcz_ [~dcz@dynamic-093-135-015-053.93.135.pool.telefonica.de] has quit [Ping timeout: 480 seconds] 21:04 -!- Guest6195 [~vkareh@00026f70.user.oftc.net] has quit [] 21:06 #dri-devel: < dwlsalmeida> airlied agd5f it isn't, that's why I am asking. I think I will run a frame through vaapi on my machine to dump the stuff from radeonsi and have a look, it will probably be a good starting point, but I will keep your suggestion in mind if I am totally stuck thanks a lot 21:06 -!- Supersaiyan_IV [~QAM@ua-85-228-153-205.bbcust.telenor.se] has quit [Read error: Connection reset by peer] 21:06 -!- Supersaiyan_IV [~QAM@ua-85-228-153-205.bbcust.telenor.se] has quit [Read error: Connection reset by peer] 21:07 -!- nchery [~nchery@50.39.99.32] has quit [] 21:07 -!- nchery [~nchery@50.39.99.32] has quit [] 21:07 -!- nchery [~nchery@50.39.99.32] has quit [] 21:08 #dri-devel: < airlied> dwlsalmeida: normally I just break on the get_*_msg functions and finish them and stare into the result structs 21:09 #dri-devel: < airlied> dwlsalmeida: for those buffers though it's normally just a matter of not caring or understanding 21:10 #dri-devel: < airlied> the fw wants what the fw wants, so you give it 2304 + 256 21:10 -!- swatish2 [~swatish2@134.134.137.87] has quit [] 21:12 -!- ZenWalker [~r00t@47.pool85-56-150.dynamic.orange.es] has quit [Ping timeout: 480 seconds] 21:12 #dri-devel: < airlied> the 256 is for segment data 21:12 #dri-devel: < airlied> so it's likely the hw just left some extra space or aligned something 21:21 -!- jsa [~jsaarine@134.191.221.82] has quit [Quit: Leaving.] 21:21 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 21:21 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 21:21 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 21:21 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 21:21 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 21:24 -!- Jeremy_Rand_Talos__ [~Jeremy_Ra@4G4AAC2EH.tor-irc.dnsbl.oftc.net] has joined #dri-devel 21:24 -!- ricotz [~ricotz@155.133.216.159] has quit [Quit: Leaving] 21:28 -!- fab [~fab@bellet.info] has quit [Quit: fab] 21:29 -!- arsenm [~Adium@82.197.100.55] has joined #radeon 21:30 -!- Jeremy_Rand_Talos_ [~Jeremy_Ra@4G4AAC2CK.tor-irc.dnsbl.oftc.net] has quit [Read error: Connection reset by peer] 21:32 -!- agd5f_ [~agd5f@76.1.162.23] has joined #freedesktop 21:32 -!- agd5f_ [~agd5f@76.1.162.23] has joined #wayland 21:32 -!- agd5f_ [~agd5f@76.1.162.23] has joined #intel-gfx 21:32 -!- agd5f_ [~agd5f@76.1.162.23] has joined #intel-3d 21:32 -!- agd5f_ [~agd5f@76.1.162.23] has joined #nouveau 21:32 -!- agd5f_ [~agd5f@76.1.162.23] has joined #radeon 21:32 -!- agd5f_ [~agd5f@76.1.162.23] has joined #dri-devel 21:32 -!- nchery [~nchery@134.134.139.80] has joined #intel-gfx 21:32 -!- nchery [~nchery@134.134.139.80] has joined #intel-3d 21:32 -!- nchery [~nchery@134.134.139.80] has joined #dri-devel 21:34 -!- Onorick [~onorick@0002c0e4.user.oftc.net] has joined #wayland 21:34 -!- Deluxe [~Deluxe@212.4.150.151] has quit [Remote host closed the connection] 21:35 -!- ZenWalker [~r00t@47.pool85-56-150.dynamic.orange.es] has joined #dri-devel 21:35 #nouveau: < fdobridge> @karolherbst🐧 any memories or ptrs where in nvgpu to look? 21:36 -!- diogenes_oftc [~diogenes_@user-5-173-112-20.play-internet.pl] has joined #nouveau 21:36 -!- ybogdano [~ybogdano@134.134.139.85] has joined #freedesktop 21:36 -!- ybogdano [~ybogdano@134.134.139.85] has joined #intel-gfx 21:36 -!- ybogdano [~ybogdano@134.134.139.85] has joined #intel-3d 21:36 -!- ybogdano [~ybogdano@134.134.139.85] has joined #dri-devel 21:36 -!- ybogdano [~ybogdano@134.134.139.85] has joined #wayland 21:39 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 21:39 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 21:39 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 21:39 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 21:39 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 21:39 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 21:39 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 21:39 #nouveau: < fdobridge> also how did we work out the sw class fix? I don't see that in my email 21:44 -!- Moprius [~Thunderbi@189.40.86.205] has joined #radeon 21:44 -!- Moprius [~Thunderbi@189.40.86.205] has joined #wayland 21:45 #nouveau: < fdobridge> ehh.. let me see.. 21:45 #nouveau: < fdobridge> @airlied search for "Global memory loads in helper invocations" 21:47 #nouveau: < fdobridge> the nvgpu stuff is gr_init_get_access_map 21:47 #nouveau: < fdobridge> and stuff using that 21:48 #nouveau: < fdobridge> or rather `get_access_map` 21:48 #nouveau: < fdobridge> my copy of that thread ends before anyone mentions a sw method 21:48 #nouveau: < fdobridge> ohh 21:48 #nouveau: < fdobridge> sw method is a software thing 21:48 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 21:48 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 21:48 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 21:48 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 21:48 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 21:48 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 21:48 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 21:48 #nouveau: < fdobridge> nouveau implements it 21:48 #nouveau: < fdobridge> there is a patch somewhere.. 21:48 #nouveau: < fdobridge> sw methods are basically interrupts on the kernel, and then the kernel handles the method from the push buffer 21:49 #nouveau: < fdobridge> which is nice, because the mmio access is switched to the correct context then 21:49 -!- Moprius [~Thunderbi@0002e253.user.oftc.net] has quit [Quit: bye] 21:49 -!- Moprius [~Thunderbi@0002e253.user.oftc.net] has quit [Quit: bye] 21:50 #nouveau: < fdobridge> oh so we just wire 604 up somewhere on the kernel side and we do the register write there? 21:50 -!- apinheiro [~infapi00@78.0.27.77.dynamic.reverse-mundo-r.com] has joined #dri-devel 21:50 #nouveau: < fdobridge> yeah 21:51 #nouveau: < fdobridge> okay I'm failing to figure out the kernel side of that 21:51 #nouveau: < fdobridge> https://gitlab.freedesktop.org/drm/nouveau/-/commit/bfe2b42ca7de5793e4b3847ca13ef305465a9492 21:52 #nouveau: < fdobridge> or rather 21:52 #nouveau: < fdobridge> https://gitlab.freedesktop.org/drm/nouveau/-/commits/topic/vulkan/ 21:52 #nouveau: < fdobridge> need all of it 21:52 #nouveau: < fdobridge> well.. the two top commits 21:53 #nouveau: < fdobridge> the method nvidia uses for this kind of stuff obviously doesn't involve kernel roundtrips, so that's why I'd like to figure it out and do the same thing instead 21:56 -!- Duke`` [~plop@lfbn-idf1-1-2098-241.w90-127.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 21:56 -!- Duke`` [~plop@lfbn-idf1-1-2098-241.w90-127.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 22:02 -!- Zopolis4 [uid504804@id-504804.ilkley.irccloud.com] has quit [] 22:04 #intel-3d: < Kayden> trying to remember why we use DWord Scattered Read/Write messages. Untyped Surface Read/Write can also handle DWord-aligned offsets 22:04 #intel-3d: < Kayden> Byte Scattered makes sense - Untyped Surface can't handle alignments < 4B 22:06 #dri-devel: < anholt_> nir_lower_precision so far increases freedreno reg pressure by 1%, instr count -.14% Now to go write unit tests and see if it's actually working as intended. 22:09 -!- YuGiOhJCJ [~YuGiOhJCJ@00021b1f.user.oftc.net] has joined #dri-devel 22:09 #intel-3d: < dj-death> diffrent fixed function? 22:14 -!- diogenes_oftc [~diogenes_@user-5-173-112-20.play-internet.pl] has quit [Quit: diogenes_oftc] 22:19 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #dri-devel 22:19 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #radeon 22:19 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #nouveau 22:19 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #intel-3d 22:19 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #intel-gfx 22:19 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #wayland 22:19 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #freedesktop 22:19 #dri-devel: < tarceri> mareko: no you want to remove varying before linking uniforms etc because you can eliminate more of the shader and uniforms 22:20 -!- rv1sr [~rv1sr@0002da44.user.oftc.net] has quit [] 22:25 -!- agd5f_ [~agd5f@76.1.162.23] has joined #freedesktop 22:25 -!- agd5f_ [~agd5f@76.1.162.23] has joined #wayland 22:25 -!- agd5f_ [~agd5f@76.1.162.23] has joined #intel-gfx 22:25 -!- agd5f_ [~agd5f@76.1.162.23] has joined #intel-3d 22:25 -!- agd5f_ [~agd5f@76.1.162.23] has joined #nouveau 22:25 -!- agd5f_ [~agd5f@76.1.162.23] has joined #radeon 22:25 -!- agd5f_ [~agd5f@76.1.162.23] has joined #dri-devel 22:26 -!- hardening [~quassel@arennes-655-1-19-105.w109-218.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 22:32 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 22:32 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 22:32 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 22:32 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 22:32 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 22:32 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 22:32 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 22:32 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #freedesktop 22:32 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #wayland 22:32 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #intel-gfx 22:32 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #intel-3d 22:32 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #nouveau 22:32 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #radeon 22:32 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #dri-devel 22:32 -!- hansg [~hans@2001:1c00:c32:7800:5bfa:a036:83f0:f9ec] has joined #dri-devel 22:33 -!- hansg [~hans@2001:1c00:c32:7800:5bfa:a036:83f0:f9ec] has quit [] 22:33 #wayland: < wlb> wayland Merge request !297 opened by Alexandros Frantzis (afrantzis) client: Do not warn about attached proxies on default queue destruction. https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/297 22:33 -!- stuart [~jssummer@192.55.54.51] has quit [] 22:33 -!- stuart [~jssummer@192.55.54.51] has quit [] 22:34 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 22:34 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 22:34 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 22:34 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 22:34 -!- ybogdano [~ybogdano@134.134.139.85] has quit [Ping timeout: 480 seconds] 22:37 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 22:37 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 22:37 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 22:37 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 22:37 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 22:37 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 22:37 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 22:38 -!- ZenWalker [~r00t@47.pool85-56-150.dynamic.orange.es] has quit [Ping timeout: 480 seconds] 22:41 -!- ZenWalker [~r00t@47.pool85-56-150.dynamic.orange.es] has joined #dri-devel 22:42 #dri-devel: < karolherbst> `rusticl_llvm_gen` the horros 22:47 -!- nchery [~nchery@134.134.139.80] has quit [Ping timeout: 480 seconds] 22:47 -!- nchery [~nchery@134.134.139.80] has quit [Ping timeout: 480 seconds] 22:47 -!- nchery [~nchery@134.134.139.80] has quit [Ping timeout: 480 seconds] 23:00 -!- apinheiro [~infapi00@78.0.27.77.dynamic.reverse-mundo-r.com] has quit [Quit: Leaving] 23:00 -!- nchery [~nchery@134.134.139.80] has joined #intel-gfx 23:00 -!- nchery [~nchery@134.134.139.80] has joined #intel-3d 23:00 -!- nchery [~nchery@134.134.139.80] has joined #dri-devel 23:02 #intel-3d: < Kayden> I guess we just use dword scattered messages for scratch, but yeah, not sure why 23:03 #intel-3d: < Kayden> oh 23:03 #intel-3d: < Kayden> it exists on older HW 23:03 #intel-3d: < Kayden> untyped surface read/write only exist on gen7+ 23:03 #intel-3d: < Kayden> so, probably no reason to use it on 7+ but it's there for old HW and probably just kept getting used because it worked so *shrug* 23:04 #radeon: < cheako> Venemo: Would you prefer weekends or weekdays? I'm wanting to ask you if you've done any testing where something injects a suboptimal signal? As I've discussed, this causes the application to recreate things and even though it's impossible(that just makes it a bug) the new objects are different for me most of the time. 23:05 -!- rsjw [~rsjw@pool-138-88-60-108.washdc.fios.verizon.net] has joined #intel-gfx 23:05 -!- rsjw [~rsjw@pool-138-88-60-108.washdc.fios.verizon.net] has joined #intel-3d 23:08 #nouveau: < fdobridge> okay there seems to be some sort of priv access map you can attach to a context in the kernel, then it lets those register be programmed 23:10 #nouveau: < fdobridge> yeah 23:10 #nouveau: < fdobridge> I suspect GSP has the same thing 23:10 #nouveau: < fdobridge> most likely even configured the exact same way 23:11 #nouveau: < fdobridge> the annoying part will be to figure out if the gr firmware we got pre GSP even has it 23:11 #nouveau: < fdobridge> yeah I'm trying to find the interfaces for it 23:11 #nouveau: < fdobridge> worst case, we do SW pre GSP 23:12 #nouveau: < fdobridge> NV0080_CTRL_FIFO_GET_ENGINE_CONTEXT_PROPERTIES_ENGINE_ID_GRAPHICS_PRIV_ACCESS_MAP is one 23:12 #nouveau: < fdobridge> sounds like it 23:12 #nouveau: < fdobridge> NV2080_CTRL_GPU_PROMOTE_CTX_BUFFER_ID_PRIV_ACCESS_MAP seems to be the other side of it 23:13 #nouveau: < fdobridge> actually 23:13 #nouveau: < fdobridge> let's do the pre GSP stuff via SW 23:14 #nouveau: < fdobridge> we'll need to use it for perf counters anyway 23:14 #nouveau: < fdobridge> @airlied is there a property in the new nouveau UAPI to tell if we are on GSP or not? 23:14 #nouveau: < fdobridge> I suspect we'll want to have it for stuff like this 23:14 #nouveau: < fdobridge> could be part of the device info stuff tho 23:16 -!- gtristan [~tristan@223.38.36.241] has joined #freedesktop 23:16 #nouveau: < fdobridge> so far the new uapi is only va/sparse stuff, any other new uapi should be separate 23:17 #nouveau: < fdobridge> no point needlessly tying things together 23:17 #nouveau: < fdobridge> if we need a GSP property it should go with the GSP patches 23:18 #nouveau: < fdobridge> though the SW method availability should possibly be it's own flag somewhere 23:18 #nouveau: < fdobridge> I forsee more uAPI changes for GSP, but very separate to the uAPI changes for vma 23:20 #nouveau: < fdobridge> it does seem like skeggsb code for gsp gr setup does a bit of this already so it might be easy to add there 23:24 -!- rsjw [~rsjw@pool-138-88-60-108.washdc.fios.verizon.net] has quit [Quit: rsjw] 23:24 -!- rsjw [~rsjw@pool-138-88-60-108.washdc.fios.verizon.net] has quit [Quit: rsjw] 23:25 -!- gtristan [~tristan@223.38.36.241] has quit [Ping timeout: 480 seconds] 23:25 #intel-gfx: < hlieberman> Is there a way I can get more useful bug data for https://gitlab.freedesktop.org/drm/intel/-/issues/6916 than what I've provided? 23:26 #intel-gfx: < hlieberman> I confess, I'm not super familiar with how to get debug output from i915.... 23:28 -!- drod [~ldm@ip-95-220-105-14.bb.netbynet.ru] has quit [Remote host closed the connection] 23:29 -!- Company [~Company@ip1f1264d8.dynamic.kabel-deutschland.de] has quit [Quit: Leaving] 23:29 -!- Company [~Company@ip1f1264d8.dynamic.kabel-deutschland.de] has quit [Quit: Leaving] 23:30 -!- ngcortes [~ngcortes@134.134.139.85] has joined #intel-3d 23:30 -!- ngcortes [~ngcortes@134.134.139.85] has joined #intel-gfx 23:30 -!- ngcortes [~ngcortes@134.134.139.85] has joined #dri-devel 23:30 -!- mowcat [~mowcat@host81-155-196-87.range81-155.btcentralplus.com] has quit [Remote host closed the connection] 23:31 -!- murb [~murb@00014183.user.oftc.net] has quit [Remote host closed the connection] 23:32 -!- murb [~murb@an.der.schoenen.blauen.danu.be] has joined #nouveau 23:40 #dri-devel: < karolherbst> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21612 I'm not sorry 23:41 #radeon: < cheako> ohh, BTW the new update to NMS crashes if you do that... so test with one of the other titles I used, like Patron/DysonSP/City Skylines. 23:49 -!- xmn [~xmn@cpe-72-225-198-203.nyc.res.rr.com] has quit [Ping timeout: 480 seconds] 23:55 #nouveau: < fdobridge> <🌺​ ¿butterflies? 🌸> What are the odds of getting PMU fw from NV..... 23:59 -!- jmdaemon [~jmdaemon@0002d6bd.user.oftc.net] has quit [Ping timeout: 480 seconds] --- Log closed Wed Mar 01 00:00:33 2023