--- Log opened Mon Jan 23 00:00:00 2023 00:01 -!- jewins [~Thunderbi@192.55.54.48] has quit [Ping timeout: 480 seconds] 00:01 -!- jewins [~Thunderbi@192.55.54.48] has quit [Ping timeout: 480 seconds] 00:01 -!- jewins [~Thunderbi@192.55.54.48] has quit [Ping timeout: 480 seconds] 00:03 -!- jewins [~Thunderbi@192.55.54.48] has joined #intel-gfx 00:03 -!- jewins [~Thunderbi@192.55.54.48] has joined #dri-devel 00:03 -!- jewins [~Thunderbi@192.55.54.48] has joined #intel-3d 00:06 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 00:06 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 00:06 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 00:06 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 00:06 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 00:06 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 00:06 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 00:06 -!- radu24284303951534727071489559 [~radu242@pool-108-41-92-33.nycmny.fios.verizon.net] has quit [Remote host closed the connection] 00:08 #freedreno: < robclark> lumag, abhinav__: looks like things will go to rc8 this time around.. which gives us a bit more time (but it is still a bit late for things that touch core in intrusive ways) 00:10 -!- mmu_man [~revol@188410969.box.freepro.com] has quit [Ping timeout: 480 seconds] 00:11 #dri-devel: < DemiMarie> jenatali: I had not thought of secondary command buffers. 00:12 #dri-devel: < DemiMarie> I thought that the command buffers were handled by what is essentially a hardware state machine. 00:15 -!- kts [~kts@103.73.237.238] has quit [Quit: Leaving] 00:15 -!- kts [~kts@103.73.237.238] has quit [Quit: Leaving] 00:15 -!- kts [~kts@103.73.237.238] has quit [Quit: Leaving] 00:15 -!- kts [~kts@103.73.237.238] has quit [Quit: Leaving] 00:16 -!- mmu_man [~revol@82-65-227-82.subs.proxad.net] has joined #nouveau 00:27 #radeon: < Venemo> mareko, pepp: are you guys aware of the Firefox GPU hangs on GFX11? 00:34 -!- iive [~iive@87.119.101.204.client.entry.bg] has quit [Quit: They came for me...] 00:34 -!- iive [~iive@87.119.101.204.client.entry.bg] has quit [Quit: They came for me...] 00:34 -!- iive [~iive@87.119.101.204.client.entry.bg] has quit [Quit: They came for me...] 00:42 -!- caveman [~caveman@0002bdf0.user.oftc.net] has joined #wayland 00:44 -!- cvmn [~caveman@7YZAABBBN.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 00:49 -!- kts [~kts@103.73.237.223] has joined #dri-devel 00:49 -!- kts [~kts@103.73.237.223] has joined #intel-3d 00:49 -!- kts [~kts@103.73.237.223] has joined #intel-gfx 00:49 -!- kts [~kts@103.73.237.223] has joined #wayland 00:51 -!- cphealy [~cphealy@2603-8001-4200-6311-92a0-3d53-9224-b276.res6.spectrum.com] has joined #dri-devel 00:54 -!- fodasso [~oftc-webi@2804:7f0:b440:413f:c206:c3ff:fe03:875f] has quit [Remote host closed the connection] 00:54 -!- fodasso [~oftc-webi@2804:7f0:b440:413f:c206:c3ff:fe03:875f] has quit [Remote host closed the connection] 00:56 -!- kts [~kts@103.73.237.223] has quit [Quit: Leaving] 00:56 -!- kts [~kts@103.73.237.223] has quit [Quit: Leaving] 00:56 -!- kts [~kts@103.73.237.223] has quit [Quit: Leaving] 00:56 -!- kts [~kts@103.73.237.223] has quit [Quit: Leaving] 00:59 -!- jarthur [~jarthur@2603-8080-1500-1a3e-cd70-9dc6-49ce-ff28.res6.spectrum.com] has quit [Ping timeout: 480 seconds] 00:59 -!- jarthur [~jarthur@2603-8080-1500-1a3e-cd70-9dc6-49ce-ff28.res6.spectrum.com] has quit [Ping timeout: 480 seconds] 01:15 -!- jewins [~Thunderbi@192.55.54.48] has quit [Ping timeout: 480 seconds] 01:15 -!- jewins [~Thunderbi@192.55.54.48] has quit [Ping timeout: 480 seconds] 01:15 -!- jewins [~Thunderbi@192.55.54.48] has quit [Ping timeout: 480 seconds] 01:15 -!- jdavies__ [~jdavies@165.1.216.62] has quit [Remote host closed the connection] 01:17 -!- zzoon[m] is now known as zzoon_holidays_till_Tuesday[m] 01:17 -!- zzoon[m] is now known as zzoon_holidays_till_Tuesday[m] 01:17 -!- smallville7123 [~small@cpe-172-193-200-97.qld.foxtel.net.au] has joined #wayland 01:24 -!- jewins [~Thunderbi@192.55.54.48] has joined #intel-gfx 01:24 -!- jewins [~Thunderbi@192.55.54.48] has joined #dri-devel 01:24 -!- jewins [~Thunderbi@192.55.54.48] has joined #intel-3d 01:28 #freedreno: < abhinav__> robclark thats good to know. I will try to validate and review some pieces of wide planes this week. If we can land the core bits of PSR this week and see how it goes that would be great 01:34 -!- molinari [~molinari@176-172-98-151.abo.bbox.fr] has quit [Ping timeout: 480 seconds] 01:34 -!- Daanct12 [~danct12@0002be7e.user.oftc.net] has joined #dri-devel 01:34 -!- Daanct12 [~danct12@0002be7e.user.oftc.net] has joined #lima 01:42 -!- co1umbarius [~columbari@muedsl-82-207-236-087.citykom.de] has joined #dri-devel 01:42 -!- co1umbarius [~columbari@muedsl-82-207-236-087.citykom.de] has joined #wayland 01:44 -!- columbarius [~columbari@muedsl-82-207-236-181.citykom.de] has quit [Ping timeout: 480 seconds] 01:44 -!- columbarius [~columbari@muedsl-82-207-236-181.citykom.de] has quit [Ping timeout: 480 seconds] 01:50 -!- Brainium [~brainium@00028330.user.oftc.net] has quit [Ping timeout: 480 seconds] 01:50 -!- Brainium [~brainium@00028330.user.oftc.net] has quit [Ping timeout: 480 seconds] 01:55 -!- kts [~kts@103.73.237.223] has joined #dri-devel 01:55 -!- kts [~kts@103.73.237.223] has joined #intel-3d 01:55 -!- kts [~kts@103.73.237.223] has joined #intel-gfx 01:55 -!- kts [~kts@103.73.237.223] has joined #wayland 01:57 -!- brkho [~quassel@irc.brkho.com] has quit [Remote host closed the connection] 02:01 -!- ahartmetz [~horst@2001:9e8:24c:c600:d016:9a2c:b74a:5ed0] has quit [Quit: Konversation terminated!] 02:07 -!- fmuellner [~fmuellner@78.30.26.40] has quit [Ping timeout: 480 seconds] 02:13 -!- Jeremy_Rand_Talos [~Jeremy_Ra@7YZAABDO8.tor-irc.dnsbl.oftc.net] has quit [Remote host closed the connection] 02:14 -!- Jeremy_Rand_Talos [~Jeremy_Ra@7YZAABES5.tor-irc.dnsbl.oftc.net] has joined #dri-devel 02:14 -!- bvivekan__ [~bvivekan@192.55.79.173] has joined #intel-gfx 02:14 -!- Fxzxmic [~fxzxmic@46.20.109.109] has joined #wayland 02:15 -!- kts [~kts@103.73.237.223] has quit [Quit: Leaving] 02:15 -!- kts [~kts@103.73.237.223] has quit [Quit: Leaving] 02:15 -!- kts [~kts@103.73.237.223] has quit [Quit: Leaving] 02:15 -!- kts [~kts@103.73.237.223] has quit [Quit: Leaving] 02:17 -!- Leopold_ [~quassel@7MPAAAAPE.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 02:17 -!- Leopold_ [~quassel@7MPAAAAPE.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 02:17 -!- Leopold_ [~quassel@7MPAAAAPE.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 02:17 -!- Leopold_ [~quassel@7MPAAAAPE.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 02:17 -!- Leopold_ [~quassel@7MPAAAAPE.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 02:17 -!- Leopold_ [~quassel@7MPAAAAPE.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 02:17 -!- Leopold_ [~quassel@7MPAAAAPE.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 02:17 -!- Leopold_ [~quassel@7MPAAAAPE.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 02:17 -!- Leopold_ [~quassel@7MPAAAAPE.tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds] 02:18 -!- Daanct12 [~danct12@0002be7e.user.oftc.net] has quit [Ping timeout: 480 seconds] 02:18 -!- Daanct12 [~danct12@0002be7e.user.oftc.net] has quit [Ping timeout: 480 seconds] 02:19 -!- Daanct12 [~danct12@0002be7e.user.oftc.net] has joined #lima 02:19 -!- Daanct12 [~danct12@0002be7e.user.oftc.net] has joined #dri-devel 02:21 -!- bvivekan_ [~bvivekan@122.166.101.63] has quit [Ping timeout: 480 seconds] 02:25 -!- Company [~Company@ip1f1264d8.dynamic.kabel-deutschland.de] has quit [Quit: Leaving] 02:25 -!- Company [~Company@ip1f1264d8.dynamic.kabel-deutschland.de] has quit [Quit: Leaving] 02:27 -!- smallville7123 [~small@cpe-172-193-200-97.qld.foxtel.net.au] has quit [Read error: Connection reset by peer] 02:28 -!- smallville7123 [~small@cpe-172-193-200-97.qld.foxtel.net.au] has joined #wayland 02:29 -!- Daaanct12 [~danct12@0002be7e.user.oftc.net] has joined #lima 02:29 -!- Daaanct12 [~danct12@0002be7e.user.oftc.net] has joined #dri-devel 02:32 -!- Daanct12 [~danct12@0002be7e.user.oftc.net] has quit [Ping timeout: 480 seconds] 02:32 -!- Daanct12 [~danct12@0002be7e.user.oftc.net] has quit [Ping timeout: 480 seconds] 02:56 -!- jewins [~Thunderbi@192.55.54.48] has quit [Ping timeout: 480 seconds] 02:56 -!- jewins [~Thunderbi@192.55.54.48] has quit [Ping timeout: 480 seconds] 02:56 -!- jewins [~Thunderbi@192.55.54.48] has quit [Ping timeout: 480 seconds] 03:15 -!- cool110 [~mark@0002e01f.user.oftc.net] has quit [Remote host closed the connection] 03:16 -!- cool110 [~mark@0002e01f.user.oftc.net] has joined #wayland 03:28 -!- ximion [~ximion@ip-176-199-211-178.um44.pools.vodafone-ip.de] has quit [] 03:33 -!- lemonzest [~lemonzest@cpc86080-nott19-2-0-cust160.12-2.cable.virginm.net] has quit [Quit: WeeChat 3.6] 03:33 -!- lemonzest [~lemonzest@cpc86080-nott19-2-0-cust160.12-2.cable.virginm.net] has quit [Quit: WeeChat 3.6] 03:39 -!- heat_ [~heat@2001:8a0:7280:5801:9441:3dce:686c:bfc7] has quit [Ping timeout: 480 seconds] 03:39 -!- heat_ [~heat@2001:8a0:7280:5801:9441:3dce:686c:bfc7] has quit [Ping timeout: 480 seconds] 03:39 -!- heat_ [~heat@2001:8a0:7280:5801:9441:3dce:686c:bfc7] has quit [Ping timeout: 480 seconds] 03:40 -!- DodoGTA [~DodoGTA@5.20.104.245] has quit [Ping timeout: 480 seconds] 03:40 -!- DodoGTA [~DodoGTA@5.20.104.245] has quit [Ping timeout: 480 seconds] 03:51 -!- smallville7123 [~small@cpe-172-193-200-97.qld.foxtel.net.au] has quit [Ping timeout: 480 seconds] 03:51 -!- mmu_man [~revol@82-65-227-82.subs.proxad.net] has quit [Ping timeout: 480 seconds] 03:51 -!- lemonzest [~lemonzest@cpc86080-nott19-2-0-cust160.12-2.cable.virginm.net] has joined #dri-devel 03:51 -!- lemonzest [~lemonzest@cpc86080-nott19-2-0-cust160.12-2.cable.virginm.net] has joined #radeon 03:55 -!- Daaanct12 [~danct12@0002be7e.user.oftc.net] has quit [Quit: Leaving] 03:55 -!- Daaanct12 [~danct12@0002be7e.user.oftc.net] has quit [Quit: Leaving] 04:07 -!- gijoe-3000 [~gijoe_3k@50.234.163.163] has joined #nouveau 04:12 -!- nerdopolis [~quassel@pool-74-97-44-96.prvdri.fios.verizon.net] has quit [Ping timeout: 480 seconds] 04:13 #dri-devel: < DemiMarie> bnieuwenhuizen: what I really want is some evidence from Intel of the security of the firmware. 04:13 -!- gijoe3000 [~gijoe_3k@93.95.229.244] has quit [Ping timeout: 480 seconds] 04:14 -!- dviola [~diego@0002b89a.user.oftc.net] has quit [Ping timeout: 480 seconds] 04:14 -!- dviola [~diego@0002b89a.user.oftc.net] has quit [Ping timeout: 480 seconds] 04:14 -!- dviola [~diego@0002b89a.user.oftc.net] has quit [Ping timeout: 480 seconds] 04:14 -!- dviola [~diego@0002b89a.user.oftc.net] has quit [Ping timeout: 480 seconds] 04:14 -!- dviola [~diego@0002b89a.user.oftc.net] has quit [Ping timeout: 480 seconds] 04:15 -!- dviola [~diego@187.66.112.167] has joined #intel-gfx 04:15 -!- dviola [~diego@187.66.112.167] has joined #intel-3d 04:15 -!- dviola [~diego@187.66.112.167] has joined #radeon 04:15 -!- dviola [~diego@187.66.112.167] has joined #nouveau 04:15 -!- dviola [~diego@187.66.112.167] has joined #dri-devel 04:17 -!- dviola [~diego@187.66.112.167] has left #intel-gfx [] 04:17 -!- dviola [~diego@187.66.112.167] has left #intel-3d [] 04:17 -!- dviola [~diego@187.66.112.167] has left #radeon [] 04:18 -!- dviola [~diego@187.66.112.167] has left #nouveau [] 04:18 -!- dviola [~diego@187.66.112.167] has left #dri-devel [] 04:19 -!- dviola [~diego@0002b89a.user.oftc.net] has joined #intel-gfx 04:19 -!- dviola [~diego@0002b89a.user.oftc.net] has joined #intel-3d 04:19 -!- dviola [~diego@0002b89a.user.oftc.net] has joined #radeon 04:19 -!- dviola [~diego@0002b89a.user.oftc.net] has joined #nouveau 04:19 -!- dviola [~diego@0002b89a.user.oftc.net] has joined #dri-devel 04:20 -!- Fxzxmic [~fxzxmic@46.20.109.109] has quit [Remote host closed the connection] 04:21 -!- Fxzxmic [~fxzxmic@46.20.109.109] has joined #wayland 04:39 #dri-devel: < Lynne> airlied: for some reason rdna2 supports av1 at 422, maybe we should wire support for it 04:40 #dri-devel: < Lynne> or at least vadumpcaps says it does, no idea if it lies or not, but it does say it outputs 422 with nv12 and p010, which is wrong 04:45 -!- adixit [~adixit@134.134.137.81] has quit [] 04:45 -!- unerlige [~unerlige@134.134.137.81] has quit [] 04:45 -!- unerlige [~unerlige@134.134.137.81] has quit [] 05:17 -!- sumits [~sumits@ec2-54-225-101-41.compute-1.amazonaws.com] has joined #dri-devel 05:17 -!- sumits [~sumits@ec2-54-225-101-41.compute-1.amazonaws.com] has joined #freedesktop 05:17 -!- sumits [~sumits@ec2-54-225-101-41.compute-1.amazonaws.com] has joined #freedreno 05:19 -!- mindraj [~crispr@94.45.199.217] has joined #wayland 05:20 -!- JohnDoe_71Rus [~CLDX@80.78.195.138] has joined #radeon 05:27 -!- gijoe-3000 [~gijoe_3k@50.234.163.163] has quit [] 05:50 -!- jgrulich [~jgrulich@dynamic-2a00-1028-9942-709e-ddf9-9ddc-36fb-0830.ipv6.o2.cz] has joined #wayland 05:51 -!- Fxzxmic [~fxzxmic@46.20.109.109] has quit [Remote host closed the connection] 05:52 -!- Fxzxmic [~fxzxmic@n220246250139.netvigator.com] has joined #wayland 05:54 -!- swatish2 [~swatish2@134.134.137.87] has joined #intel-gfx 05:54 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has quit [Ping timeout: 480 seconds] 05:58 -!- YuGiOhJCJ [~YuGiOhJCJ@00021b1f.user.oftc.net] has joined #dri-devel 06:05 #etnaviv: < tomeu> looks like a neat board 06:06 #etnaviv: < tomeu> what base board will you be using with it? 06:10 -!- floof58 is now known as Guest2164 06:10 -!- floof58 is now known as Guest2164 06:10 -!- floof58 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has joined #radeon 06:10 -!- floof58 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has joined #wayland 06:10 #dri-devel: < airlied> Lynne: not sure vaapi always reports that I think it'll do internal copies 06:13 -!- Guest2164 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has quit [Ping timeout: 480 seconds] 06:13 -!- Guest2164 [~floof58@2a01:118f:620:5c00:5b5c:587d:9e9e:d473] has quit [Ping timeout: 480 seconds] 06:13 -!- itoral [~itoral@117.49.60.213.dynamic.reverse-mundo-r.com] has joined #dri-devel 06:13 -!- itoral [~itoral@117.49.60.213.dynamic.reverse-mundo-r.com] has joined #freedesktop 06:13 -!- fredldotme [~fredldotm@217-149-170-88.nat.highway.telekom.at] has quit [Remote host closed the connection] 06:14 -!- fredldotme [~fredldotm@217-149-170-88.nat.highway.telekom.at] has joined #lima 06:16 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:773e:719b:6aae:59c4] has joined #dri-devel 06:16 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:773e:719b:6aae:59c4] has joined #intel-gfx 06:16 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:773e:719b:6aae:59c4] has joined #nouveau 06:16 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:773e:719b:6aae:59c4] has joined #radeon 06:16 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:773e:719b:6aae:59c4] has joined #wayland 06:20 -!- kts [~kts@103.73.236.37] has joined #dri-devel 06:20 -!- kts [~kts@103.73.236.37] has joined #intel-3d 06:20 -!- kts [~kts@103.73.236.37] has joined #intel-gfx 06:20 -!- kts [~kts@103.73.236.37] has joined #wayland 06:20 -!- fredldotme [~fredldotm@217-149-170-88.nat.highway.telekom.at] has quit [] 06:22 -!- ondracka [~oftc-webi@rosat.physics.muni.cz] has quit [Quit: Page closed] 06:24 -!- Jeremy_Rand_Talos [~Jeremy_Ra@7YZAABES5.tor-irc.dnsbl.oftc.net] has quit [Remote host closed the connection] 06:24 -!- Jeremy_Rand_Talos [~Jeremy_Ra@4G4AABXJL.tor-irc.dnsbl.oftc.net] has joined #dri-devel 06:24 -!- hogander [~jhogande@134.191.220.81] has joined #intel-gfx 06:28 #dri-devel: < Lynne> to convert pixfmts? yuck 06:29 #dri-devel: < Lynne> it does advertise p016 for all other codecs, though, which is direct 06:29 #dri-devel: < Lynne> probably a missing line 06:30 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #freedesktop 06:30 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #wayland 06:30 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #intel-gfx 06:30 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #intel-3d 06:30 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #nouveau 06:30 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #radeon 06:30 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #dri-devel 06:31 -!- bgs [~bgs@212-85-160-171.dynamic.telemach.net] has joined #dri-devel 06:31 #dri-devel: < airlied> Lynne: I'd have to test vaapi with 420 and 422 to see what it actually programs the hw 06:32 -!- kts [~kts@103.73.236.37] has quit [Quit: Leaving] 06:32 -!- kts [~kts@103.73.236.37] has quit [Quit: Leaving] 06:32 -!- kts [~kts@103.73.236.37] has quit [Quit: Leaving] 06:32 -!- kts [~kts@103.73.236.37] has quit [Quit: Leaving] 06:33 #dri-devel: < airlied> Lynne: h264 might support it as well 06:34 -!- vyivel [~vyivel@eclair.cafe] has quit [Remote host closed the connection] 06:34 -!- vyivel [~vyivel@eclair.cafe] has quit [Remote host closed the connection] 06:34 -!- vyivel [~vyivel@eclair.cafe] has quit [Remote host closed the connection] 06:34 -!- vyivel [~vyivel@eclair.cafe] has joined #dri-devel 06:34 -!- vyivel [~vyivel@eclair.cafe] has joined #freedesktop 06:34 -!- vyivel [~vyivel@eclair.cafe] has joined #wayland 06:34 -!- TMM [hp@amanda.tmm.cx] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 06:34 -!- TMM [hp@amanda.tmm.cx] has joined #dri-devel 06:35 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 06:35 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 06:35 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 06:35 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 06:35 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 06:35 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 06:35 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 06:37 -!- pret7 [~abhishek@pool-71-105-205-179.nycmny.fios.verizon.net] has quit [] 06:38 -!- kts [~kts@103.73.236.37] has joined #dri-devel 06:38 -!- kts [~kts@103.73.236.37] has joined #intel-3d 06:38 -!- kts [~kts@103.73.236.37] has joined #intel-gfx 06:38 -!- kts [~kts@103.73.236.37] has joined #wayland 06:39 #dri-devel: < airlied> Lynne: status queries for anv should work noe 06:39 #dri-devel: < airlied> now 06:43 -!- fab [~fab@bellet.info] has joined #dri-devel 06:45 #dri-devel: < Lynne> I'll test it 06:45 -!- ricotz [~ricotz@155.133.217.57] has joined #nouveau 06:54 #dri-devel: < Lynne> yup, it 06:54 #dri-devel: < Lynne> it's working 06:56 #dri-devel: < Lynne> do you need a command line to generate 422 samples? 06:59 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #wayland 06:59 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #radeon 06:59 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #nouveau 06:59 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #intel-gfx 06:59 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #intel-3d 06:59 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #freedesktop 06:59 -!- danvet [~Daniel@0002b820.user.oftc.net] has joined #dri-devel 07:06 -!- sozuba [~sozuba@49.207.193.198] has joined #wayland 07:07 #dri-devel: < airlied> Lynne: yeah throw some at me 07:09 -!- mindraj [~crispr@94.45.199.217] has quit [Quit: Leaving] 07:11 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has joined #dri-devel 07:11 -!- itoral [~itoral@117.49.60.213.dynamic.reverse-mundo-r.com] has quit [Remote host closed the connection] 07:11 -!- itoral [~itoral@117.49.60.213.dynamic.reverse-mundo-r.com] has quit [Remote host closed the connection] 07:11 -!- itoral [~itoral@117.49.60.213.dynamic.reverse-mundo-r.com] has joined #freedesktop 07:11 -!- itoral [~itoral@117.49.60.213.dynamic.reverse-mundo-r.com] has joined #dri-devel 07:14 #dri-devel: < Lynne> ffmpeg -i -c:v libx264 -pix_fmt yuv422p -y test_422.mkv 07:15 -!- bgs [~bgs@212-85-160-171.dynamic.telemach.net] has quit [Remote host closed the connection] 07:15 #dri-devel: < Lynne> for 10bit 422, s/yuv422p/yuv422p10 07:19 #dri-devel: < airlied> just going to try and get anv to pass cts before I get to that 07:19 #dri-devel: < Lynne> kk 07:20 #dri-devel: < Lynne> what is radv waiting for to get the patchset merged? 07:21 #dri-devel: < airlied> more review I think 07:22 -!- ad__ [~prefetch@2a01:4f8:c2c:5a84::1] has quit [] 07:22 -!- ad__ [~prefetch@mail.kernel-space.org] has joined #etnaviv 07:22 #dri-devel: < airlied> so really either bnieuwenhuizen or hakzsam to throw some more criticism at it :-P 07:22 #dri-devel: < Lynne> btw you can replace libx264 with libx265 for hevc, just keep in mind it'll generate a rext file due to a bug 07:22 #dri-devel: < airlied> though in fixing anv I'm seeing some minor fixes for radv 07:23 #dri-devel: < Lynne> you can still decode them fine (probably) by passing -hwaccel_flags +allow_profile_mismatch before -i when decoding 07:28 -!- hardening [~quassel@arennes-655-1-65-190.w109-218.abo.wanadoo.fr] has joined #wayland 07:32 -!- dcz_ [~dcz@dynamic-002-244-055-074.2.244.pool.telefonica.de] has joined #wayland 07:33 -!- jfalempe [~jfalempe@2a01:e0a:c:37e0:38da:a7d9:7cc9:db3e] has joined #dri-devel 07:33 -!- alanc [~alanc@148.87.23.6] has quit [Remote host closed the connection] 07:33 -!- alanc [~alanc@148.87.23.6] has quit [Remote host closed the connection] 07:34 -!- alanc [~alanc@148.87.23.6] has joined #dri-devel 07:34 -!- alanc [~alanc@148.87.23.6] has joined #freedesktop 07:38 -!- molinari [~molinari@176-172-98-151.abo.bbox.fr] has joined #wayland 07:38 -!- kzd [~kzd@static-198-54-130-100.cust.tzulo.com] has quit [Quit: kzd] 07:38 -!- kzd [~kzd@static-198-54-130-100.cust.tzulo.com] has quit [Quit: kzd] 07:40 -!- fab [~fab@bellet.info] has quit [Quit: fab] 07:40 -!- sgruszka [~sgruszka@134.191.220.81] has joined #dri-devel 07:43 -!- miracolix [~snuckls@p4fd1ad0e.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 07:52 -!- djrscally [~djrscally@cpc141996-chfd3-2-0-cust928.12-3.cable.virginm.net] has quit [Read error: Connection reset by peer] 07:53 -!- itoral_ [~itoral@117.49.60.213.dynamic.reverse-mundo-r.com] has joined #freedesktop 07:53 -!- itoral_ [~itoral@117.49.60.213.dynamic.reverse-mundo-r.com] has joined #dri-devel 07:57 -!- manuel1985 [~manuel198@62.99.131.178] has joined #wayland 08:00 -!- itoral [~itoral@117.49.60.213.dynamic.reverse-mundo-r.com] has quit [Ping timeout: 480 seconds] 08:00 -!- itoral [~itoral@117.49.60.213.dynamic.reverse-mundo-r.com] has quit [Ping timeout: 480 seconds] 08:01 -!- mvlad [~mvlad@2a02:2f08:470d:8800:24d7:51ff:fed6:906d] has joined #dri-devel 08:01 -!- mvlad [~mvlad@2a02:2f08:470d:8800:24d7:51ff:fed6:906d] has joined #wayland 08:01 -!- mvlad [~mvlad@2a02:2f08:470d:8800:24d7:51ff:fed6:906d] has joined #etnaviv 08:01 -!- mvlad [~mvlad@2a02:2f08:470d:8800:24d7:51ff:fed6:906d] has joined #freedesktop 08:01 -!- sghuge [~sagar@134.134.139.71] has joined #intel-3d 08:01 -!- sghuge [~sagar@134.134.139.71] has joined #intel-gfx 08:01 -!- sghuge [~sagar@134.134.139.71] has joined #dri-devel 08:01 -!- rasterman [~rasterman@cpc99584-brnt1-2-0-cust1380.4-2.cable.virginm.net] has joined #dri-devel 08:01 -!- rasterman [~rasterman@cpc99584-brnt1-2-0-cust1380.4-2.cable.virginm.net] has joined #wayland 08:04 #radeon: < mareko> yes 08:05 -!- a1batross [39b1386cf2@2a00:c70:1:178:170:40:189:1] has joined #dri-devel 08:05 #dri-devel: < airlied> okay anv passes all the current CTS tests 08:06 #dri-devel: < airlied> or will once I rebase/push it 08:06 #dri-devel: * airlied is wondering can I do separate dpb/dst on inte 08:06 #dri-devel: < airlied> intel 08:08 #dri-devel: < airlied> ah no I just misread my code, coincide it is 08:14 -!- fab [~fab@134.214.236.142] has joined #dri-devel 08:20 -!- Fxzxmic [~fxzxmic@n220246250139.netvigator.com] has quit [Remote host closed the connection] 08:20 -!- Fxzxmic [~fxzxmic@46.20.109.109] has joined #wayland 08:22 #dri-devel: < dj-death> airlied: it's just on SKL? 08:23 -!- scrumplex [~quassel@p5b3206be.dip0.t-ipconnect.de] has quit [Quit: Quassel - Signing Off] 08:24 -!- scrumplex [~quassel@p5b3206be.dip0.t-ipconnect.de] has joined #freedesktop 08:24 -!- nuh^ [~nuh@c-24-30-76-89.hsd1.ga.comcast.net] has quit [Remote host closed the connection] 08:27 #dri-devel: < airlied> dj-death: SKL+ though I have to test it on DG2 to make sure it works on both ends of the spectrum 08:28 #dri-devel: * airlied doesn't have an integrated gen11/12 08:28 #dri-devel: < airlied> h265 is also going to be messy as I think for the as specced vulkan API it would need HuC 08:29 #dri-devel: < airlied> I have to work out if my DG2 board loads huc at all, I fell down the twisty mei paths 08:29 #dri-devel: < airlied> dj-death: Lynne tested on an SKL, and I've testing on a whiskylake so far 08:37 -!- pochu [~pochu@87.red-88-30-59.staticip.rima-tde.net] has joined #wayland 08:37 -!- pochu [~pochu@87.red-88-30-59.staticip.rima-tde.net] has joined #dri-devel 08:40 -!- kts [~kts@103.73.236.37] has quit [Quit: Leaving] 08:40 -!- kts [~kts@103.73.236.37] has quit [Quit: Leaving] 08:40 -!- kts [~kts@103.73.236.37] has quit [Quit: Leaving] 08:40 -!- kts [~kts@103.73.236.37] has quit [Quit: Leaving] 08:46 -!- frankbinns [~frankbinn@66.159.216.5] has joined #dri-devel 08:48 -!- jsa [~jsaarine@134.191.220.83] has joined #intel-gfx 08:49 -!- jsa [~jsaarine@134.191.220.83] has quit [] 08:56 -!- kts [~kts@103.73.236.37] has joined #dri-devel 08:56 -!- kts [~kts@103.73.236.37] has joined #intel-3d 08:56 -!- kts [~kts@103.73.236.37] has joined #intel-gfx 08:56 -!- kts [~kts@103.73.236.37] has joined #wayland 08:57 -!- kts [~kts@103.73.236.37] has quit [Remote host closed the connection] 08:57 -!- kts [~kts@103.73.236.37] has quit [Remote host closed the connection] 08:57 -!- kts [~kts@103.73.236.37] has quit [Remote host closed the connection] 08:57 -!- kts [~kts@103.73.236.37] has quit [Remote host closed the connection] 08:58 -!- Deluxef [~Deluxe@212.4.150.151] has joined #radeon 08:59 -!- tursulin [~tursulin@134.191.227.52] has joined #intel-gfx 08:59 -!- tursulin [~tursulin@134.191.227.52] has joined #dri-devel 08:59 -!- tursulin [~tursulin@134.191.227.52] has joined #intel-3d 09:00 -!- lynxeye [~lynxeye@2a02:560:5898:3f00:20e1:7881:a58b:630d] has joined #etnaviv 09:00 -!- lynxeye [~lynxeye@2a02:560:5898:3f00:20e1:7881:a58b:630d] has joined #dri-devel 09:01 -!- Deluxe [~Deluxe@212.4.150.151] has joined #radeon 09:02 #dri-devel: < dj-death> airlied: appears to load fine on my dg2 09:02 #dri-devel: < dj-death> airlied: I'm on drm-tip 6.2.0-rc3+ 09:02 #dri-devel: < dj-death> just need the right version of the blob 09:05 -!- ahartmetz [~horst@2001:9e8:269:2e00:cfa3:9eb4:398a:8013] has joined #wayland 09:07 #dri-devel: < MrCooper> daniels danvet emersion jekstrand: if user-mode queues & fences and Vulkan wait-before-submit semantics can be handled in the kernel (which seems required for UMF to be usable by display servers), do we really need explicit sync in the display protocols? 09:08 -!- ice99 [~ice9@kernelone.com] has joined #dri-devel 09:08 -!- ice99 [~ice9@kernelone.com] has joined #intel-gfx 09:09 -!- vliaskov [~vliaskov@dynamic-078-054-160-047.78.54.pool.telefonica.de] has joined #dri-devel 09:09 -!- vliaskov [~vliaskov@dynamic-078-054-160-047.78.54.pool.telefonica.de] has joined #nouveau 09:10 -!- jkrzyszt [~jkrzyszt@134.191.227.56] has joined #intel-gfx 09:10 -!- jkrzyszt [~jkrzyszt@134.191.227.56] has joined #dri-devel 09:12 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has quit [Ping timeout: 480 seconds] 09:14 #dri-devel: < danvet> MrCooper, can it be handled in the kernel? 09:15 #dri-devel: < MrCooper> which part specifically? 09:15 #dri-devel: < danvet> well thus far I've seen some hand-waving that we just stuff umf into dma_resv somehow on the sideline 09:15 #dri-devel: < danvet> and pretend everything keeps working 09:15 #dri-devel: < danvet> but also the handle umf wait before submit in the kernel 09:16 #dri-devel: < danvet> like generally with umf you handle this in userspace by putting the right waits into the userspace queue 09:16 #dri-devel: < MrCooper> if UMF is to be usable for display servers, the kernel has to be involved somehow, doesn't it? 09:16 #dri-devel: < danvet> I also haven't seen a reasonable plan for umf vs dma_fence compat mode 09:16 #dri-devel: < danvet> the hand-waving just assumes everything is umf in your system 09:16 #dri-devel: < danvet> why? 09:16 #dri-devel: < danvet> also how? 09:17 #dri-devel: < danvet> with umf you get no guarantee it'll ever happen 09:17 #dri-devel: < MrCooper> Wayland compositors want something which can be plugged into an event loop, not "putting the right waits into the userspace queue" 09:17 #dri-devel: < danvet> so either compositor waits until it's signalled before it submits 09:17 #dri-devel: < danvet> or you put a magic queue wait with timeout into the command queue 09:17 #dri-devel: < danvet> then it's not really pure umf anymore 09:18 #dri-devel: < MrCooper> yeah, "pure UMF" seems unusable for Wayland compositors 09:18 #dri-devel: < danvet> and the trouble with augmented umf so that it kinda looks like a futex with pollable fd 09:18 #dri-devel: < danvet> you get into the entire "looks almost like dma_fence, but is entirely incompatible with that" mess 09:19 #dri-devel: < danvet> and since we need legacy dma_fence supporting mode anyway for the foreseeable future 09:19 #dri-devel: < MrCooper> entirely incompatible how? 09:19 #dri-devel: < danvet> I'd just use that and call it done 09:19 #dri-devel: < danvet> kernel deadlocks in memory reclaim 09:19 -!- dtmrzgl [~dtmrzgl@192.198.151.51] has joined #intel-gfx 09:19 #dri-devel: < danvet> so you can do dma_fence built using umf primitives 09:19 #dri-devel: < danvet> even with userspace submit and all that 09:19 #dri-devel: < MrCooper> even with a timeout? 09:19 #dri-devel: < danvet> but then you ditch the entire nice future fences semantics of umf 09:19 #dri-devel: < danvet> mutex_lock_timeout does not fix a deadlock 09:19 -!- GNUmoon [~GNUmoon@0002d696.user.oftc.net] has quit [Remote host closed the connection] 09:19 -!- GNUmoon [~GNUmoon@0002d696.user.oftc.net] has quit [Remote host closed the connection] 09:19 -!- GNUmoon [~GNUmoon@0002d696.user.oftc.net] has quit [Remote host closed the connection] 09:20 #dri-devel: < MrCooper> sounds like Vulkan wait-before-submit semantics can't be safely supported at all? 09:20 #dri-devel: < danvet> there's the tdr timeout for jobs that take too long, but usually when people talk about timeout in umf context they mean essentially replacing mutex_lock with mutex_lock_timeout and having no plan for what happens when the timeout fails because you've managed to hit the architectural deadlock 09:20 #dri-devel: < danvet> yes 09:21 #dri-devel: < danvet> which is the big scary thing and the reason jekstrand wants to ditch 09:21 #dri-devel: < MrCooper> somebody should tell James Jones that 09:21 #dri-devel: < danvet> well, wait-before-submit can be supported, that's what the entire drm_syncobj and mesa submit thread stuff is about 09:21 #dri-devel: < danvet> but there's some older wait before submit vk stuff which wasn't this carefully engineering (mostly könig saying no really) 09:22 #dri-devel: < danvet> and which just works mostly, but not by design 09:22 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has joined #etnaviv 09:22 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has joined #dri-devel 09:22 #dri-devel: < danvet> i.e. if you get a cpu fault at just the right time that gets into memory reclaim and hits just the right dma_fence, you functionally deadlock 09:22 #dri-devel: < danvet> tdr will clean up the mess, but you have a reset for something that vk spec says should work 09:22 #dri-devel: < MrCooper> submit thread won't fly either I'm afraid, per discussion on the explicit sync Wayland protocol 09:22 #dri-devel: < danvet> hm link for me to catch up? 09:23 #dri-devel: < MrCooper> sec 09:23 -!- peterz [~quassel@j130084.upc-j.chello.nl] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 09:23 #dri-devel: < danvet> MrCooper, for the vk feature that's very gray on linux-dma_fence world ask jekstrand 09:23 #dri-devel: < danvet> I always forget the exact name 09:24 -!- peterz [~quassel@24.132.130.84] has joined #radeon 09:24 -!- GNUmoon [~GNUmoon@0002d696.user.oftc.net] has joined #nouveau 09:24 -!- GNUmoon [~GNUmoon@0002d696.user.oftc.net] has joined #radeon 09:24 -!- GNUmoon [~GNUmoon@0002d696.user.oftc.net] has joined #freedesktop 09:24 #dri-devel: < MrCooper> danvet: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90#note_1017021 09:28 #dri-devel: < MrCooper> vkQueuePresentKHR is not supposed to block either 09:35 #wayland: < pq> bl4ckb0ne, yeah, OpenXR has the problem that it is a multi-platform API. Doing things that are specific to an OS, like getting a fd, is a pain for them, I've been told. I do agree with you. Just poke the OpenXR upstream more and persistently to show you're serious. 09:36 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has joined #dri-devel 09:36 #wayland: < pq> I did mention a blocking API is bad to someone, but because I'm not actually building anything with OpenXR, I was just shrugged off saying it's too complicated for a multi-platform API. 09:38 #dri-devel: < MrCooper> danvet: FWIW, I can't seem to find the reference right now, but I understand AMD's plans for user-space queues is to signal dma_fences from user space for implicit sync 09:38 #dri-devel: < danvet> yeah you can do that 09:38 #dri-devel: < danvet> if you do it right 09:38 #dri-devel: < danvet> I'm honestly not confident from the discussions thus far 09:38 #dri-devel: < MrCooper> isn't it fundamentally the same thing as wait-before-signal though? 09:39 #dri-devel: < danvet> not if you do it right :-) 09:39 #wayland: < emersion> maybe a Unix-specific API would be enough 09:39 #dri-devel: < danvet> essentially what you need is a) pin memory like with ioctl submit until each request is done 09:39 #wayland: < emersion> s/API/extension/ 09:40 #wayland: < pq> yeah 09:40 #dri-devel: < danvet> have an in-kernel timeline to make sure your ctx is advancing monotonically and in finite time 09:40 #dri-devel: < danvet> (that was b)) 09:40 #dri-devel: < danvet> c) nuke the entire gpu context if userspace violates this 09:40 #dri-devel: < danvet> d) which means any wait-before-signal trick you do in the command stream that doesn't work with ioctl submit will also not work with this 09:41 #dri-devel: < danvet> at least work reliably as in "guaranteed to not occasionally deadlock and end up nuking the app" 09:42 #dri-devel: < danvet> MrCooper, ok read the wl proto issue, and yes daniels is right 09:42 #dri-devel: < danvet> unless you handle the dma_fence materialization in the protocol on the compositor side 09:42 #dri-devel: < danvet> then there's no way to implement this client-side only without breaking some guarantee somewhere 09:43 #dri-devel: < MrCooper> dma_fence materialization as in once the signal has been submitted for the wait? 09:43 #dri-devel: < danvet> yeah 09:43 #dri-devel: < MrCooper> would still need something usable in an event loop for that 09:43 #dri-devel: < danvet> yeah that's why I put my POLL_PRI comment at the bottom 09:44 #dri-devel: < danvet> if we want to tack it onto the drm_syncobj fd 09:44 #dri-devel: < danvet> or we do a new one 09:44 #dri-devel: < danvet> whatever compositors like really 09:45 #dri-devel: < MrCooper> but that still couldn't avoid the deadlock issues in the kernel, could it? 09:45 #dri-devel: < danvet> MrCooper, I think for compositor design it's useful to distinguish dma_fence + drm_syncobj case, where we can do all kinds of things like pollable fd and clear point of "the kernel is committed and guarantees it'll happen" 09:45 #dri-devel: < danvet> and pure umf, which is a memory location with no guarantees whatsoever about what'll happen to it in the future 09:46 #dri-devel: < danvet> MrCooper, drm_syncobj doesn't deadlock, because you cannot submit an un-materialized fence as a dependency anywhere 09:46 #dri-devel: < danvet> the "wait for fence materialization" is why the mesa submit thread is a thing 09:47 #dri-devel: < danvet> which means the kernel doesn't die, but otoh mesa might not be able to guarantee what the vk/wl specs say 09:47 #dri-devel: < danvet> which is why this is all a bit annoying :-/ 09:48 #dri-devel: < MrCooper> yeah, seems like a thread can't really work, and it's not supposed to block either 09:49 #dri-devel: < danvet> yeah I mean fundamentally the problem doesn't disappear 09:49 #dri-devel: < danvet> by moving it into userspace 09:49 #dri-devel: < danvet> so you still have the mismatch between what the spec wants and what linux delivers 09:50 #dri-devel: < MrCooper> James Jones still seems to be under the impression it can work, that's why he's insisting on explicit sync support (in X as well) 09:50 #dri-devel: < danvet> I think fundamentally you can't have a) dynamic gpu memory management b) future fences c) compositors not getting stuck (i.e. cross security boundary guarantees) d) bottomless queues everywhere (no blocking) 09:50 #dri-devel: < danvet> nvidia blob largely drops a) on the floor 09:51 #dri-devel: < danvet> then this is all trivial 09:51 -!- Fxzxmic [~fxzxmic@46.20.109.109] has quit [Remote host closed the connection] 09:52 -!- Fxzxmic [~fxzxmic@46.20.109.109] has joined #wayland 09:52 #dri-devel: < MrCooper> what a mess :/ 09:52 #dri-devel: < danvet> I think they defacto also drop c) and just shrug 09:53 -!- mauld [~comwa@46.101.73.70] has quit [Quit: WeeChat 3.5] 09:53 -!- mauld [~comwa@46.101.73.70] has quit [Quit: WeeChat 3.5] 09:53 -!- mauld [~comwa@46.101.73.70] has quit [Quit: WeeChat 3.5] 09:53 #dri-devel: < danvet> but one of these you really have to drop or it boils down to fully abstract diagram that demonstrates the deadlock 09:58 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #dri-devel 09:58 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #etnaviv 09:58 -!- YuGiOhJCJ [~YuGiOhJCJ@00021b1f.user.oftc.net] has quit [Quit: YuGiOhJCJ] 10:02 #dri-devel: < emersion> the protocol should support submitting fences that didn't materialize yet 10:06 #dri-devel: < emersion> what's wrong with waiting for UMF in the kernel with a timeout, like a Wayland compositor would? 10:07 #dri-devel: < dolphin> emersion: that's indeed the question :) 10:08 #dri-devel: < dolphin> I guess it boils down to a lot of code has been designed that just assumes that fence always materializes in the next 10 seconds, so that UMF would have to be a new construct compared to dma_fence 10:10 #dri-devel: < emersion> is a 10s timeout bad? 10:11 #dri-devel: < dolphin> the waiters don't have a timeout, the exporter gives a guarantee to either fulfill or fail the fence in that time 10:16 -!- mmu_man [~revol@2a01:e0a:8c9:4100:b1b2:420f:d569:ce50] has joined #nouveau 10:18 -!- Duke`` [~plop@2a01cb000797780084555bcf152507a7.ipv6.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 10:18 -!- Duke`` [~plop@2a01cb000797780084555bcf152507a7.ipv6.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 10:19 -!- Duke`` [~plop@2a01cb000797780084555bcf152507a7.ipv6.abo.wanadoo.fr] has joined #dri-devel 10:19 -!- Duke`` [~plop@2a01cb000797780084555bcf152507a7.ipv6.abo.wanadoo.fr] has joined #intel-gfx 10:23 #dri-devel: < emersion> i don't really understand any of this 10:23 #dri-devel: < danvet> emersion, yeah if you wait for umf in the kernel you just rebuild the mesa submit thread in the kernel 10:23 #dri-devel: < emersion> yes 10:23 #dri-devel: < danvet> that's a pile of code on the wrong side of a security boundary 10:23 #dri-devel: < emersion> that bad? 10:23 #dri-devel: < emersion> well, it would only be for backwards compat 10:23 #dri-devel: < danvet> mesa exists already 10:24 #dri-devel: < emersion> is waiting a security issue? 10:24 #dri-devel: < danvet> nah but doing all the parsing and copying and stuffing it into a kthread :-) 10:24 #dri-devel: < emersion> oh there is parsing involved? 10:24 #dri-devel: < danvet> if you want perfect backwards compat with existing ioctl at least 10:25 #dri-devel: < MrCooper> it would waste CPU cycles too? 10:25 #dri-devel: < danvet> if not, then ... mesa submit thread and drm_syncob wait-for-materialize all exists and works 10:25 #dri-devel: < emersion> i thought it was just waiting for a bit in some chunk of memory 10:25 #dri-devel: < danvet> MrCooper, well if you don't write a fastpath 10:25 #dri-devel: < danvet> so more complexity in a legacy submit ioctl which a) tend to be complex already b) why would you touch them 10:25 #dri-devel: < emersion> i mean there is probably a way to wait for a UMF without wasting CPU cycles? 10:26 #dri-devel: < danvet> emersion, what dolphin said, you need to wait for umf at a different place than where all the current drivers wait for dma_fence 10:26 #dri-devel: < emersion> where is that place exaclty? 10:26 #dri-devel: < danvet> emersion, the cpu wasting is copying all the stuff to the kthread 10:26 #dri-devel: < danvet> after drm_sched_job_submit() essentially 10:26 #dri-devel: < danvet> umf wait must be before that 10:27 -!- AbleBacon [~AbleBacon@136.32.93.57] has quit [Read error: Connection reset by peer] 10:27 #dri-devel: < danvet> which also means you get propagating umf, because the dma_fence you hand back to userspace also becomes an umf 10:27 #dri-devel: < danvet> it's an infectious property 10:27 #dri-devel: < danvet> and with drm_syncobj we have the in-kernel semantics to at least stall in the right place 10:27 #dri-devel: < danvet> with sync_file not even that is a thing 10:28 #dri-devel: < emersion> okay, then we are in a situation similar to format modifiers, where everybody needs to support it in the whole stack before they can be used? 10:28 #dri-devel: < danvet> neither in dma_resv 10:28 #dri-devel: < danvet> and if you don't patch all these and the drivers using them, it's not good for more than a quick "hey this looks easy" demo 10:28 #dri-devel: < danvet> emersion, I think so 10:29 #dri-devel: < danvet> but I think I'm also more pessimistic on this than others 10:29 -!- mauld [~comwa@46.101.73.70] has joined #intel-gfx 10:29 -!- mauld [~comwa@46.101.73.70] has joined #dri-devel 10:30 -!- mauld [~comwa@46.101.73.70] has joined #intel-3d 10:30 #dri-devel: < danvet> I don't think it's more code in the kernel than userspace 10:30 #dri-devel: < danvet> but also not less at all, and putting all that for compat in the kernel instead of userspace just feels rather wrong 10:31 #dri-devel: < emersion> i'm not convinced about that, but i'm no kernel dev 10:31 #dri-devel: < bnieuwenhuizen> on the other hand if nobody comes up with alternatives for years ... 10:31 #dri-devel: < danvet> bnieuwenhuizen, I haven't seen more than handwaving on the kernel side either 10:33 #dri-devel: < Lynne> how would mcbp work with user-mode submits? 10:36 #dri-devel: < MrCooper> so to recap, it sounds like Vulkan wait-before-signal can't be fully supported with upstream drivers; assuming user-mode fences are handled at the kernel level in a way suitable for Wayland compositors, is explicit sync really needed in the display protocols? 10:36 #dri-devel: < MrCooper> Lynne: GPU FW needs to handle it presumably 10:37 #dri-devel: < emersion> wait-before-submit* (?) 10:37 -!- smallville7123 [~small@cpe-172-193-72-46.qld.foxtel.net.au] has joined #wayland 10:37 #dri-devel: < MrCooper> wait-before-signal as in the GPU wait is submitted before the corresponding signal 10:38 -!- smallville7123 is now known as Guest2177 10:38 -!- small [~small@116.90.72.61] has joined #wayland 10:38 -!- small is now known as smallville7123 10:38 #dri-devel: < danvet> MrCooper, imo yes 10:38 #dri-devel: < emersion> i mean that's what's happening in general, people wait before signal, and the wait is unblocked when the signal happens 10:38 #dri-devel: < emersion> or maybe my terminology is completely wrong 10:38 #dri-devel: < danvet> like if protocols really can't be fixed, then I guess we can add an umf slot to dma_buf as another iteration of the most hilarious ipc ever 10:38 #dri-devel: < danvet> which mesa stuffs in on one side and takes out on the other 10:38 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has joined #freedesktop 10:38 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has joined #dri-devel 10:38 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has joined #radeon 10:39 #dri-devel: < danvet> kinda like the import/export ioctl that jekstrand landed 10:39 #dri-devel: < danvet> but I'm really not sure whether ipc-on-dmabuf is a great design 10:39 #dri-devel: < emersion> yeah, i'd rather not 10:39 #dri-devel: < MrCooper> danvet: the protocols can be fixed, I'm just wondering if there will be any tangible benefit from the churn 10:39 #dri-devel: < dolphin> right, but if kernel is just metadata carrier, still can't do dynamic memory management really 10:39 #dri-devel: < danvet> it's probably the quickest hack forward which isn't a design dumpster fire at a fundamental level though 10:40 #dri-devel: < danvet> dolphin, you'd need to use the mesa submit threads still 10:40 #dri-devel: < emersion> well, having a good design sounds like a tangible benefit to me 10:40 #dri-devel: < emersion> instead of stashing more stuff onto dmabufs 10:40 #dri-devel: < danvet> it's really just a "wl proto is immutable, let's add the missing field to the dma-buf ipc sidechannel" :-) 10:40 #dri-devel: < emersion> wl proto is not immutable 10:40 #dri-devel: < emersion> i can work on the proto side 10:40 #dri-devel: < emersion> i just need folks to fix the rest :P 10:40 #dri-devel: * danvet firmly tongue-in-cheek :-) 10:40 #dri-devel: < dolphin> emersion: asking everyone to move away from dma-buf to new_fence, will be bit of a job 10:41 #dri-devel: < danvet> but yeah the dma-buf ipc approach would only need changes to dma-buf.c and mesa winsys 10:41 #dri-devel: < danvet> well, more or less in exactly the same places as the dma-buf fence import/export 10:41 #dri-devel: < MrCooper> wouldn't it use the dma-buf fence import/export? 10:42 #dri-devel: < emersion> it doesn't have to be a flagday migration 10:42 -!- srslypascal is now known as Guest2178 10:42 #dri-devel: < danvet> ok gtg now for lunch/workout/sauna, ttyl 10:42 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has joined #dri-devel 10:42 #dri-devel: < danvet> MrCooper, it's not a dma_fence/sync_file, so it'd be need 10:42 #dri-devel: < emersion> it can be a gradual migration like format modifiers 10:42 #dri-devel: < danvet> *new 10:42 -!- Guest2177 [~small@cpe-172-193-72-46.qld.foxtel.net.au] has quit [Read error: Connection reset by peer] 10:42 #dri-devel: < danvet> or you're back to the "magic compat layer in the kernel" pandora's box 10:43 #dri-devel: < MrCooper> emersion: nvidia users would keep suffering from synchronization artifacts until the gradual migration completes 10:43 #dri-devel: < emersion> is nvidia migrating to UMF today? 10:44 #dri-devel: < emersion> hm, or do you mean nvidia is completely broken today? 10:44 #dri-devel: < MrCooper> emersion: re wait-before-signal, so far the kernel supports submitting GPU waits only after the corresponding signal was submitted 10:45 #dri-devel: < emersion> i'm not following 10:45 #dri-devel: < emersion> i submit a page-flip IOCTL before the GPU work for the frame has completed 10:45 #dri-devel: < dolphin> emersion: today you're not allowed to publish a fence unless you guarantee to be able to resolve it 10:45 #dri-devel: < MrCooper> emersion: yes, https://gitlab.freedesktop.org/xorg/xserver/-/issues/1317 10:45 #dri-devel: < emersion> the kernel will wait until the completion is signalled 10:45 #dri-devel: < emersion> this is wait-before-signal 10:45 #dri-devel: < MrCooper> not the same thing 10:46 #dri-devel: < MrCooper> wait-before-signal is about GPU semaphores 10:46 #dri-devel: < emersion> what is signal() then? it's not signalling completion of the fence? 10:46 #dri-devel: < emersion> is signal() the thing that materializes the fence? 10:47 #dri-devel: < MrCooper> emersion: BTW, nvidia doesn't even do implicit sync for page flips yet, so may get incomplete frames even for normal compositor drawing 10:47 #dri-devel: < MrCooper> signalling the semaphore 10:47 -!- Guest2178 [~srslypasc@0002bff5.user.oftc.net] has quit [Remote host closed the connection] 10:48 -!- sgruszka [~sgruszka@134.191.220.81] has quit [Ping timeout: 480 seconds] 10:48 #dri-devel: < emersion> somehow i'm more confused at the end of the discussion than at the start 10:49 #dri-devel: < emersion> okay, so nvidia is broken, but since this is a sync issue, it only manifests itself in some edge cases 10:49 #dri-devel: < MrCooper> it is a complex topic :) 10:49 #dri-devel: < dolphin> emersion: just having a fence somewhere returned by IOCTL means it'll have to be signalled in <10 seconds 10:49 #dri-devel: < dolphin> if you have a reference to a fence, it exists and you can expect it to fulfil or fail in that time period 10:50 #dri-devel: < emersion> right, if we have UMF waits in the kernel, we can keep that guarantee 10:50 #dri-devel: < dolphin> so you can do stuff like just plain wait it, holding the system making forward progress until it signals 10:50 -!- kts [~kts@103.73.237.247] has joined #dri-devel 10:50 -!- kts [~kts@103.73.237.247] has joined #intel-3d 10:50 -!- kts [~kts@103.73.237.247] has joined #intel-gfx 10:50 -!- kts [~kts@103.73.237.247] has joined #wayland 10:50 #dri-devel: < emersion> yes 10:51 #dri-devel: < dolphin> well, you'd have to fix all users of dma fences in the kernel not to do that 10:51 #dri-devel: < emersion> why? 10:51 #dri-devel: < emersion> can't the dma_fence emulation for UMF record the creation time 10:51 -!- manuel_ [~manuel198@62.99.131.178] has joined #wayland 10:51 #dri-devel: < emersion> and timneout if the wait exceeds that timestamp+10s? 10:51 #dri-devel: < dolphin> UMF fence means there's no guarantee when it will complete => potential memory management deadlocks 10:52 #dri-devel: < emersion> UMF with a timeout fixes that issue 10:52 #dri-devel: < dolphin> well, everybody is mostly after UMF for the fact that there would be no exporter enforced timeout 10:53 #dri-devel: < dolphin> so UMF with fixed timeout doesn't really sound that much better than current dma fences 10:53 -!- devilhorns [~devilhorn@2601:80:c980:7400::f1d5] has joined #wayland 10:53 -!- devilhorns [~devilhorn@2601:80:c980:7400::f1d5] has joined #dri-devel 10:53 #dri-devel: < emersion> i mean, if there is a timeout for backwards-compat only, could be fine? 10:53 -!- heat [~heat@0002b861.user.oftc.net] has joined #dri-devel 10:53 -!- heat [~heat@0002b861.user.oftc.net] has joined #intel-gfx 10:53 -!- heat [~heat@0002b861.user.oftc.net] has joined #intel-3d 10:54 #dri-devel: < dolphin> well, then you would essentially have two classes of dma fence 10:54 #dri-devel: < dolphin> which really is kind of equal to the new fence which danvet and I referred to 10:54 #dri-devel: < emersion> yeah, it would be a new fence, but with possible backwards compat with old dma_fence 10:55 #dri-devel: < emersion> and then we can have a new-fence wl proto, KMS uAPI, etc 10:55 #dri-devel: < dolphin> the thing is, because you can chain those fences 10:55 #dri-devel: < dolphin> you basically have to fix pretty much all of it before you get the benefit 10:55 -!- X512 [~vision@softbank126080186102.bbtec.net] has joined #dri-devel 10:55 -!- X512 [~vision@softbank126080186102.bbtec.net] has joined #radeon 10:55 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has quit [Ping timeout: 480 seconds] 10:55 #dri-devel: < emersion> yeah, you need to fix one driver + one compositor + mesa 10:56 #dri-devel: < emersion> to not hit the backwards compat dma_fence codepath 10:56 #dri-devel: < X512> Why 2 types of syncronization FD exists (fence file, syncobj)? Is fence file obsolete? 10:56 #dri-devel: < emersion> X512: i'd suggest reading the kernel docs for drm_syncobj 10:57 #dri-devel: < X512> It seems that it is possible to implement everything in userland by using only syncobj FDs. 10:57 #dri-devel: < emersion> https://dri.freedesktop.org/docs/drm/gpu/drm-mm.html#drm-sync-objects 10:57 #dri-devel: < X512> fence faile is redurant. 10:57 #dri-devel: < X512> faile -> file 10:57 -!- manuel1985 [~manuel198@62.99.131.178] has quit [Ping timeout: 480 seconds] 10:58 #dri-devel: < dolphin> emersion: well, the problem is if you export the fence, it can be imported by pretty much anybody 10:58 #dri-devel: < dolphin> so you'd have to change the rules based on who imports it 10:58 -!- alarumbe [~lrmb@0002d1a4.user.oftc.net] has quit [Ping timeout: 480 seconds] 10:58 -!- alarumbe [~lrmb@0002d1a4.user.oftc.net] has quit [Ping timeout: 480 seconds] 10:58 -!- alarumbe [~lrmb@0002d1a4.user.oftc.net] has quit [Ping timeout: 480 seconds] 10:58 -!- alarumbe [~lrmb@0002d1a4.user.oftc.net] has quit [Ping timeout: 480 seconds] 10:58 -!- alarumbe [~lrmb@0002d1a4.user.oftc.net] has quit [Ping timeout: 480 seconds] 10:59 #dri-devel: < dolphin> suddenly it would be your responsibility as exporter to ensure 10 second timeout, compared to the importer deciding it depending on if they are up for indefinitive timeout 10:59 #dri-devel: < emersion> there are multiple ways to go around this 11:00 #dri-devel: < emersion> hm, are you talking about export inside the kernel, or export as a FD? 11:00 #dri-devel: < dolphin> FD, mostly 11:00 #dri-devel: < emersion> so you could have a new FD type for new-fence 11:00 #dri-devel: < emersion> and exporting to a dma_fence would change the rules 11:01 #dri-devel: < dolphin> well, then you can loop back to what I said about getting all the userspace libraries to jump a new fence FD type 11:01 #dri-devel: < dolphin> everyone seems to be figuring things out by doing downstream hacks on top of dma_buf for now 11:02 #dri-devel: < dolphin> in upstream, you only export immovable pinned memory 11:02 #etnaviv: < tomeu> austriancoder: btw, I started looking at opencl image support, and looks like the blob on the npu uses opcode 0x79 for image reads 11:03 #etnaviv: < tomeu> which is currently: 11:03 #etnaviv: < tomeu> 11:03 #dri-devel: < emersion> there are not that many userspace libraries 11:03 #dri-devel: < X512> I asked about fence file and syncobj accessed from userland. Why not use syncobj FD for Wayland explicit sync protrocol? 11:03 #etnaviv: < austriancoder> tomeu: jup.. seen that too 11:03 #dri-devel: < emersion> X512: because UMF may need a New Thing 11:03 #etnaviv: < austriancoder> on some gles3 demo 11:03 #dri-devel: < X512> It have no wait before submit problem. 11:03 #dri-devel: < emersion> so the wl work is stalled on kernel folks figuring out what the New Thing can be 11:03 #etnaviv: < tomeu> oh, a compute shader? 11:03 #dri-devel: < dolphin> emersion: how's that? if you include media and compute 11:04 #dri-devel: < kchibisov> How would I debug memory issues within just libEGL? Are there options to build only libEGL under ASAN? 11:04 #etnaviv: < austriancoder> tomeu: can tell you more when day job ends 11:04 #etnaviv: < tomeu> sure 11:04 -!- jdavies [~jdavies@222.194.90.146.dyn.plus.net] has joined #dri-devel 11:05 -!- jdavies is now known as Guest2180 11:05 #dri-devel: < kchibisov> I have libEGL segfaulting when handling linux dmabuf v4 with a specific client on my system due to malloc errors. 11:05 #dri-devel: < emersion> dolphin: i mostly care about KMS and Vulkan 11:05 #dri-devel: < dolphin> emersion: and with compute, I also mean the scale-out network stuff 11:06 #dri-devel: < dolphin> well, that doesn't mean the libraries are not there, just means you don't care about them :) 11:07 -!- jdavies_ [~jdavies@66.159.216.5] has joined #dri-devel 11:07 #dri-devel: < emersion> do you mean oneAPI crap? 11:07 #dri-devel: < emersion> VA-API? 11:07 #dri-devel: < emersion> or something else? 11:08 #dri-devel: < emersion> in any case, i don't care if these degrade to the backwards compat path 11:08 #dri-devel: < dolphin> well, the kernel backwards compatibility rules really apply to everyone 11:09 #dri-devel: < dolphin> I think libfabric is the hip thing these days for compute 11:09 #dri-devel: < MrCooper> X512: don't think you can get a syncobj before the signalling work has been submitted; anyway, that particular use cases seems a lost cause for upstream drivers 11:10 #dri-devel: < dolphin> the problem is that those libraries and the compute in general is the reason why folks want the new fence 11:10 #dri-devel: < emersion> MrCooper: you can with timelines 11:11 #dri-devel: < emersion> send a timeline drm_syncobj with a point which doesn't exist yet 11:11 #dri-devel: < dolphin> yeah, I think there is a corner case in Vulkan that will outright fail on upstream 11:11 #dri-devel: < X512> And DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT flag. 11:11 #dri-devel: < emersion> hm actaully you might also be able to do it with binary syncobj 11:11 #dri-devel: < dolphin> fixing just that corner case is probably not enough of motivation to do all the work 11:11 #dri-devel: < emersion> the syncobj is a container and the drm_fence in it can be NULL 11:12 #dri-devel: < emersion> dma_fence* 11:12 -!- alarumbe [~lrmb@82-69-11-11.dsl.in-addr.zen.co.uk] has joined #dri-devel 11:12 -!- alarumbe [~lrmb@82-69-11-11.dsl.in-addr.zen.co.uk] has joined #etnaviv 11:12 -!- alarumbe [~lrmb@82-69-11-11.dsl.in-addr.zen.co.uk] has joined #intel-gfx 11:12 -!- alarumbe [~lrmb@82-69-11-11.dsl.in-addr.zen.co.uk] has joined #radeon 11:12 -!- alarumbe [~lrmb@82-69-11-11.dsl.in-addr.zen.co.uk] has joined #wayland 11:12 #dri-devel: < X512> WAIT_FOR_SUBMIT will cause to wait until dma_fence will be inserted to syncobj. 11:13 -!- Guest2180 [~jdavies@222.194.90.146.dyn.plus.net] has quit [Ping timeout: 480 seconds] 11:14 #dri-devel: < emersion> related: https://patchwork.freedesktop.org/patch/506761/ 11:14 -!- Company [~Company@ip1f1264d8.dynamic.kabel-deutschland.de] has joined #dri-devel 11:14 -!- Company [~Company@ip1f1264d8.dynamic.kabel-deutschland.de] has joined #wayland 11:17 #dri-devel: < MrCooper> maybe it's "just" prone to deadlocks in the kernel then 11:19 #dri-devel: < emersion> X512: btw, the wl proto based on drm_sycnobj is here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90 11:29 #freedesktop: < siddh> hi, i dont know why but i got logged out of my freedesktop gitlab account and now I can't seem to login. I can't even open profile page, it asks to log in. Is the profile deleted? (Username: siddh) 11:30 #freedesktop: < siddh> I had used gitlab oauth to login, and had changed username. Now when I used it to login, it apparently created a new account (?) instead of logging into the existing one... 11:30 #freedesktop: < emersion> it seems like it's gone 11:30 #freedesktop: < emersion> bentiss: maybe a false positive in your script? 11:33 -!- Harzilein [harzi@harzilein.eu.org] has quit [Quit: ircII EPIC5-2.1.7 -- Are we there yet?] 11:33 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Ping timeout: 480 seconds] 11:33 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Ping timeout: 480 seconds] 11:33 -!- doppo [~doppo@107.191.100.185] has quit [Remote host closed the connection] 11:34 -!- Deluxe [~Deluxe@212.4.150.151] has quit [Remote host closed the connection] 11:35 #dri-devel: < MrCooper> or maybe you can get a syncobj like that, but still can't actually submit the GPU wait work before the signal work 11:36 -!- doppo [~doppo@107.191.100.185] has joined #wayland 11:36 #dri-devel: < emersion> vulkan lacks an ext to import a drm_syncobj, so yeah you can't do that right now 11:36 #dri-devel: < emersion> you can if you stay in vulkan-land 11:37 -!- jsa [~jsaarine@134.191.220.83] has joined #intel-gfx 11:37 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #dri-devel 11:37 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #etnaviv 11:37 #dri-devel: < X512> Isn't Vulkan timeline semaphore exported opaque FD actually syncobj FD? 11:38 #dri-devel: < emersion> oh, right 11:38 #dri-devel: < emersion> but there's no guarantee it will be 11:38 #dri-devel: < emersion> it's just the mesa implementation-defined behavior 11:38 #dri-devel: < X512> It cah be qualified by new Vulkan extension like dma_buf export FD extension. 11:39 #dri-devel: < emersion> yes, but jekstrand rejected that idea 11:39 #dri-devel: < emersion> on the basis that UMF will likely need a new fence, and we should skip directly to that 11:39 #dri-devel: < emersion> the tl;dr is that all explicit sync work is stalled on UMF being solved, as you can see 11:40 -!- MajorBiscuit [~MajorBisc@145.94.182.137] has joined #dri-devel 11:40 -!- MajorBiscuit [~MajorBisc@145.94.182.137] has joined #freedesktop 11:40 -!- MajorBiscuit [~MajorBisc@145.94.182.137] has joined #intel-gfx 11:40 -!- MajorBiscuit [~MajorBisc@145.94.182.137] has joined #nouveau 11:40 -!- MajorBiscuit [~MajorBisc@145.94.182.137] has joined #radeon 11:40 -!- MajorBiscuit [~MajorBisc@145.94.182.137] has joined #wayland 11:40 -!- sav10 [~sav@177.12.16.193] has quit [] 11:40 #dri-devel: < bnieuwenhuizen> I feel like we're falling into a trap of blocking everything on UMF and then being very slow to get UMF though 11:40 #dri-devel: < emersion> yes, i agree 11:40 -!- Szadek [~Szadek@169.150.201.10] has quit [Quit: WeeChat 3.8] 11:41 #dri-devel: < dolphin> the real question is, is there some use case you can't implement without new fence when it comes to 3D/compositors 11:41 #dri-devel: < bnieuwenhuizen> like Jason mentioned 2-4 years for UMF yesterday, which kinda sucks to block any ecosystem improvements 11:42 #dri-devel: < dolphin> usually, new fence enters the discussion when you want to do multiple-hour compute workloads 11:42 -!- sgruszka [~sgruszka@134.191.220.81] has joined #dri-devel 11:42 #dri-devel: < emersion> dolphin: fix NVIDIA, and future AMD hw 11:43 #dri-devel: < emersion> also wait-before-submit for WSI 11:43 #dri-devel: < X512> What is Vulkan semaphore FD for proprietary Nvidia drivers? 11:43 #dri-devel: < emersion> X512: no idea 11:43 #dri-devel: < dolphin> emersion: nvidia can also adapt the same model everyone else is doing 11:44 #dri-devel: < emersion> dolphin: future hw won't support the current model 11:44 #dri-devel: < dolphin> why wouldn't 10 second timeout be supported? 11:45 #dri-devel: < emersion> might as well move on now, instead of staying with the old model which will become obsolete eventually 11:45 #dri-devel: < dolphin> if one failed to perform an action in 10 seconds, your compositor/desktop experience is not going to be great 11:46 #dri-devel: < emersion> i don't know the details, i just know AMD will require UMF in the future 11:47 #dri-devel: < dolphin> they probably would like to take advantage of HW features that you can achieve with UMF (like everyone else) 11:47 #dri-devel: < dolphin> doesn't make it any more required for the desktop compositing and 3D workloads 11:48 #dri-devel: < emersion> the ML has more info 11:48 #dri-devel: < dolphin> now matter how complex your hardware, you can always assert 10 second timeout 11:49 #etnaviv: < tomeu> wonder how samplers are supposed to work, I don't see the texture's address anywhere in the command stream 11:49 #dri-devel: < X512> Does it mean that applications will be able to freeze whole GUI for 10 seconds? 11:49 #dri-devel: < emersion> no 11:50 #dri-devel: < dolphin> if you do your compositor right, should just freeze single window 11:50 #dri-devel: < dolphin> but if your compositor has a bug (or the underlying userspace driver), then you might 11:51 #dri-devel: < dolphin> meaning if the compositor itself hangs, then you may get 10 second stutter 11:51 #dri-devel: < dolphin> and that is the rationale for the timeout too, any more time and the user is going to hit the power button 11:54 #dri-devel: < dolphin> emersion: long story short, you can always assert a timeout even if your hardware could do something else, and you can make/keep the fence waiting kernel code more straightforward 11:54 #dri-devel: < dolphin> as a new FD would be needed, sharing the same name in kernel internally may just add confusion 11:55 #dri-devel: < dolphin> everyone would probably just want the new fence, but nobody has enough incentive to do it as everyone would have to be on board to get the benefits 11:55 #dri-devel: < dolphin> as one can always resolve the problems just for your own driver and stack in downstream 11:58 #freedesktop: < bentiss> siddh: 3 possibilities: either you have been banned/removed because of misconduct, either your new usersname was using a keyword from https://gitlab.freedesktop.org/freedesktop/helm-gitlab-omnibus/-/blob/master/configs/packet-HA/fdo-approve-users.gotmpl#L10-20, either you did not have any activity in gitlab.fd.o and we disable those accounts automatically (same script) because 11:58 #freedesktop: < bentiss> 99% of the time they are spam 11:59 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Ping timeout: 480 seconds] 11:59 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Ping timeout: 480 seconds] 11:59 #freedesktop: < bentiss> siddh: there is also the possibility of a manual mistake from an admin, but we tend to not do that 12:00 #freedesktop: < bentiss> siddh: of course your account might have been legit and the script is a little bit too greedy, but you're the first one to complain since I set this up 7 months ago 12:02 -!- Szadek [~Szadek@185.254.75.49] has joined #wayland 12:03 -!- manuel1985 [~manuel198@62.99.131.178] has joined #wayland 12:04 #freedesktop: < bentiss> siddh: do you know if your account was still fine in the past 7 days? So I can have a look at the database 12:07 #dri-devel: < MrCooper> emersion: future AMD HW can work fine with what we have now (and so can nvidia HW, if they want to) 12:07 -!- manuel_ [~manuel198@62.99.131.178] has quit [Ping timeout: 480 seconds] 12:08 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #etnaviv 12:08 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #dri-devel 12:08 #dri-devel: < emersion> AMD devs are saying otherwise 12:08 #dri-devel: < MrCooper> upstream drivers can't stop supporting dma_fence anyway, it would be a UAPI regression 12:08 #dri-devel: < dolphin> emersion: probably some miscommunication going on 12:09 #dri-devel: < dolphin> nothing stops anybody from starting the 10 second timer when creating the fence 12:09 #dri-devel: < MrCooper> AMD devs seem to understand this perfectly 12:11 #dri-devel: < emersion> alright, then sounds like a good idea to just let explicit sync work bitrot a few more years 12:11 #dri-devel: < X512> I am working on proof-of-concept Radeon GPU driver that run in userland as server (daemon) process. 12:12 #dri-devel: < emersion> less work for me, i won't complain :) 12:12 #dri-devel: < X512> Targeted GPU (Radeon SI) seems too old for prototyping UMF :( 12:12 #dri-devel: < dolphin> well, as far as I know, (apart from the corner cases that Vulkan API allows) there's really no use-case for 3D/desktop compositing where you need indefinite workloads 12:13 #dri-devel: < dolphin> emersion: the answer to "why?", is really the compute libraries 12:14 #dri-devel: < X512> Haiku have no implicit sync and X11 legacy so whole synchonization model can be designed from scratch. 12:15 #dri-devel: < dolphin> X512: in userspace, unless you can pin All the Memory (TM), you can't do anything but "new fence" 12:15 #dri-devel: < dolphin> as you won't have any guarantees for memory being available 12:16 #dri-devel: < dolphin> and if you are doing shmem() + futex() in userspace, then it goes back to danvet's point about why make it in KMD? 12:17 #dri-devel: < X512> My driver guarantee that all buffer objects have actually allocated memory and creating new buffer will fail if no more physical memory. 12:17 #dri-devel: < X512> For simplity. 12:18 #dri-devel: < dolphin> if the kernel does overcommit, the allocated memory is a lie 12:18 #dri-devel: < dolphin> your thread will be paused, memory taken away, and returned at later point 12:18 #dri-devel: < X512> No overcommit. GTT buffers must be locked in physical memory. 12:19 #dri-devel: < X512> Driver reject CPU memory that is not locked. 12:19 #dri-devel: < dolphin> right, if you allow userspace to lock unbounded amount of memory, then a lot of things are possible but that's an another story 12:20 -!- Fxzxmic [~fxzxmic@46.20.109.109] has quit [Remote host closed the connection] 12:20 -!- Fxzxmic [~fxzxmic@46.20.109.109] has joined #wayland 12:22 #dri-devel: < dolphin> however your CPU thread may still be paused due to CPU timeslicing, so even if the GPU work submitted finishes, the CPU thread may not be there to pick it up 12:22 #dri-devel: < dolphin> so still can't give a guarantee of 10 seconds 12:24 #dri-devel: < X512> Do GPU preemption? 12:24 #dri-devel: < dolphin> hm? 12:25 #dri-devel: < dolphin> just that the userspace CPU thread can't make promises to complete anything in N seconds 12:25 #dri-devel: < X512> Than it is only a problem of one particular userland process and other processes unaffected? 12:26 #dri-devel: < dolphin> yes, but is the reason why you can't guarantee to signal a fence in 10 seconds 12:27 #dri-devel: < dolphin> aka. you can only do a "new fence" really if you do it in userspace 12:27 -!- chewitt [~chewitt@0002b8dc.user.oftc.net] has joined #lima 12:27 -!- chewitt [~chewitt@0002b8dc.user.oftc.net] has joined #etnaviv 12:30 #dri-devel: < X512> That is the problem with doint in userspace if ignoring legacy compatibility problems? 12:31 #dri-devel: < X512> Userland processes can be fully isolated by separate GPU contexts and GPU context switching. 12:31 #dri-devel: < dolphin> doing what, exactly? 12:31 #dri-devel: < dolphin> you mean the old style dma_fence? 12:32 #dri-devel: < X512> No. Memory mapped userland fences. 12:33 #dri-devel: < dolphin> hmm, I don't think there is a problem. every waiter is responsible for specifying a timeout 12:34 #dri-devel: < dolphin> you don't have any hard guarantees of the system making forward progress, though 12:36 #dri-devel: < X512> If freeze is isolated to single GPU context and don't affect other GPU contexts then it seems no problem. 12:39 #dri-devel: < dolphin> yeah, if it's not your compositor, then probably not a problem 12:41 #dri-devel: < X512> Compositor can render old surface buffer (double buffering) if rendering new buffer by client process is frozen for some reason. 12:42 #dri-devel: < dolphin> yeah, but if your compositor itself is frozen, then user sees no new frame :) 12:43 #dri-devel: < dolphin> of course if you assign the compositor to a different cgroup and allow it to mlock memory, the chances will be lower 12:46 #dri-devel: < X512> I think that it is good idea to prohibit overcommit for compositor and design it so every allocation failure must be gracefully handled (fail to open window etc.). 12:46 #dri-devel: < X512> Compositor is critical real time task. 12:49 -!- kts [~kts@103.73.237.247] has quit [Quit: Leaving] 12:49 -!- kts [~kts@103.73.237.247] has quit [Quit: Leaving] 12:49 -!- kts [~kts@103.73.237.247] has quit [Quit: Leaving] 12:49 -!- kts [~kts@103.73.237.247] has quit [Quit: Leaving] 13:07 -!- Fxzxmic [~fxzxmic@46.20.109.109] has quit [] 13:11 -!- itoral_ [~itoral@117.49.60.213.dynamic.reverse-mundo-r.com] has quit [Remote host closed the connection] 13:11 -!- itoral_ [~itoral@117.49.60.213.dynamic.reverse-mundo-r.com] has quit [Remote host closed the connection] 13:16 -!- mmu_man [~revol@2a01:e0a:8c9:4100:b1b2:420f:d569:ce50] has quit [Ping timeout: 480 seconds] 13:20 -!- nckncknck [~freeman@broadband-37-110-50-132.ip.moscow.rt.ru] has joined #nouveau 13:21 -!- mmu_man [~revol@188410969.box.freepro.com] has joined #nouveau 13:22 -!- JohnDoe_71Rus [~CLDX@80.78.195.138] has quit [] 13:22 #dri-devel: < Lynne> umf isn't that far away, it's just a few patchsets away from being usable 13:28 -!- fmuellner [~fmuellner@78.30.26.40] has joined #wayland 13:29 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:773e:719b:6aae:59c4] has quit [Quit: Leaving] 13:29 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:773e:719b:6aae:59c4] has quit [Quit: Leaving] 13:29 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:773e:719b:6aae:59c4] has quit [Quit: Leaving] 13:29 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:773e:719b:6aae:59c4] has quit [Quit: Leaving] 13:29 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:773e:719b:6aae:59c4] has quit [Quit: Leaving] 13:30 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:88ec:68fb:7bf2:c8c0] has joined #dri-devel 13:30 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:88ec:68fb:7bf2:c8c0] has joined #intel-gfx 13:30 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:88ec:68fb:7bf2:c8c0] has joined #nouveau 13:30 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:88ec:68fb:7bf2:c8c0] has joined #radeon 13:30 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:88ec:68fb:7bf2:c8c0] has joined #wayland 13:32 #freedesktop: < siddh> bentiss: It wasn't a banned keyword (my irc name here was my username). I could use it 2 days ago. 13:33 #freedesktop: < bentiss> siddh: k, let me dig in the backups 13:44 -!- Tom^ [~tom@h-158-174-67-168.A159.priv.bahnhof.se] has quit [] 13:47 -!- seccentral [~seccentra@matrix.ddnet.io] has joined #nouveau 13:49 -!- seccentral [~seccentra@matrix.ddnet.io] has left #nouveau [] 13:51 -!- mowcat [~mowcat@2a00:23c5:d190:1901:f22f:74ff:fe77:1e1c] has joined #radeon 13:52 #dri-devel: < MrCooper> danvet: hmm, can the kernel prevent wait-before-signal with user-mode queues though? 13:56 -!- nerdopolis [~quassel@pool-74-97-44-96.prvdri.fios.verizon.net] has joined #wayland 13:58 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has joined #dri-devel 13:59 -!- epoll [~epaul1@2400:4051:61:600:99c6:ef6:5de6:1ce5] has quit [Ping timeout: 480 seconds] 14:00 -!- ids1024 [~ids1024@0001cbfa.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:00 -!- ids1024 [~ids1024@0001cbfa.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:01 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Ping timeout: 480 seconds] 14:01 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Ping timeout: 480 seconds] 14:01 -!- fxkamd [~Thunderbi@lnsm2-torontoxn-142-116-149-103.dsl.bell.ca] has joined #radeon 14:01 -!- fxkamd [~Thunderbi@lnsm2-torontoxn-142-116-149-103.dsl.bell.ca] has joined #dri-devel 14:02 -!- sozuba [~sozuba@00028e8f.user.oftc.net] has quit [Quit: sozuba] 14:06 -!- agd5f_ [~agd5f@76.1.162.23] has joined #freedesktop 14:06 -!- agd5f_ [~agd5f@76.1.162.23] has joined #wayland 14:06 -!- agd5f_ [~agd5f@76.1.162.23] has joined #intel-gfx 14:06 -!- agd5f_ [~agd5f@76.1.162.23] has joined #intel-3d 14:06 -!- agd5f_ [~agd5f@76.1.162.23] has joined #nouveau 14:06 -!- agd5f_ [~agd5f@76.1.162.23] has joined #radeon 14:06 -!- agd5f_ [~agd5f@76.1.162.23] has joined #dri-devel 14:07 -!- epoll [~epaul1@2400:4051:61:600:30de:a595:74a6:b228] has joined #dri-devel 14:08 -!- Tom^ [~tom@h-158-174-67-168.A159.priv.bahnhof.se] has joined #nouveau 14:09 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:10 -!- ids1024 [~ids1024@iandouglasscott.com] has joined #wayland 14:10 -!- ids1024 [~ids1024@iandouglasscott.com] has joined #nouveau 14:10 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #etnaviv 14:10 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has joined #dri-devel 14:10 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has joined #dri-devel 14:12 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:12 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:12 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:12 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:12 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:12 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:12 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:13 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #freedesktop 14:13 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #wayland 14:13 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #intel-gfx 14:13 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #intel-3d 14:13 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #nouveau 14:13 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #radeon 14:13 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #dri-devel 14:17 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 14:17 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 14:17 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 14:17 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 14:17 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 14:17 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 14:17 -!- agd5f_ [~agd5f@76.1.162.23] has quit [Ping timeout: 480 seconds] 14:17 -!- p0g0 [~p0g0@23.252.179.197] has joined #wayland 14:17 -!- sozuba [~sozuba@49.207.193.198] has joined #wayland 14:18 -!- Tom^ [~tom@h-158-174-67-168.A159.priv.bahnhof.se] has quit [Read error: No route to host] 14:20 -!- kem [~kem@00012d75.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:20 -!- kem [~kem@00012d75.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:20 -!- krushia [~krushia@h134-215-110-193.cntcnh.broadband.dynamic.tds.net] has quit [Quit: Konversation terminated!] 14:20 -!- krushia [~krushia@h134-215-110-193.cntcnh.broadband.dynamic.tds.net] has quit [Quit: Konversation terminated!] 14:20 -!- alarumbe [~lrmb@0002d1a4.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:20 -!- alarumbe [~lrmb@0002d1a4.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:20 -!- alarumbe [~lrmb@0002d1a4.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:20 -!- alarumbe [~lrmb@0002d1a4.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:20 -!- alarumbe [~lrmb@0002d1a4.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:21 -!- Kruppt [~Kruppt@104.169.45.179] has joined #nouveau 14:23 #etnaviv: < tomeu> hmm, I suspect it is encoded in the instruction 14:25 #freedesktop: < bentiss> damn, recovering any information in the 174 GB sql dump is going to be hard :/ 14:27 -!- sarnex [~sarnex@066-168-117-249.res.spectrum.com] has joined #d3d9 14:27 -!- sarnex [~sarnex@066-168-117-249.res.spectrum.com] has joined #dri-devel 14:27 -!- sarnex [~sarnex@066-168-117-249.res.spectrum.com] has joined #radeon 14:32 -!- praca2 [~praca2@staticline-31-183-205-24.toya.net.pl] has joined #nouveau 14:33 -!- Tom^ [~tom@h-158-174-67-168.A159.priv.bahnhof.se] has joined #nouveau 14:33 -!- sarnex_ [~sarnex@066-189-096-125.res.spectrum.com] has quit [Ping timeout: 480 seconds] 14:33 -!- sarnex_ [~sarnex@066-189-096-125.res.spectrum.com] has quit [Ping timeout: 480 seconds] 14:33 -!- sarnex_ [~sarnex@066-189-096-125.res.spectrum.com] has quit [Ping timeout: 480 seconds] 14:34 -!- jewins [~Thunderbi@192.55.54.53] has joined #intel-gfx 14:34 -!- jewins [~Thunderbi@192.55.54.53] has joined #dri-devel 14:34 -!- jewins [~Thunderbi@192.55.54.53] has joined #intel-3d 14:45 -!- praca2_ [~praca2@staticline-31-183-205-24.toya.net.pl] has joined #nouveau 14:47 -!- praca2 [~praca2@staticline-31-183-205-24.toya.net.pl] has quit [Ping timeout: 480 seconds] 14:49 #freedesktop: < bentiss> siddh: correct me if I'm wrong, but you initially created your account on 2023-01-13 and never had any interaction with freedesktop (comment in an issue, code repository)? If so, then yes, it is expected your account to be considered as "spam". We delete such dormant accounts that are taking space in our db for nothing 14:50 -!- praca2_ [~praca2@staticline-31-183-205-24.toya.net.pl] has left #nouveau [] 14:50 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:52 -!- rasterman [~rasterman@cpc99584-brnt1-2-0-cust1380.4-2.cable.virginm.net] has quit [Read error: Connection reset by peer] 14:52 -!- rasterman [~rasterman@cpc99584-brnt1-2-0-cust1380.4-2.cable.virginm.net] has quit [Read error: Connection reset by peer] 14:54 -!- kts [~kts@103.73.237.98] has joined #dri-devel 14:54 -!- kts [~kts@103.73.237.98] has joined #intel-3d 14:54 -!- kts [~kts@103.73.237.98] has joined #intel-gfx 14:54 -!- kts [~kts@103.73.237.98] has joined #wayland 14:55 #freedesktop: < siddh> bentiss: Oh okayy. I had made a snippet or two, but I guess that doesn't really count. Thanks for checking! And sorry for bothering you... 14:55 #freedesktop: < bentiss> siddh: no worries 14:56 #freedesktop: < bentiss> siddh: yeah, snippets don't count as "actively contributing to fdo", we do have too many bots dumping their sh*t through a snippet and getting it referrenced by google and others that it brings them money 14:57 #freedesktop: < siddh> bentiss: ah i see. basically free seo for scams. Thanks 14:57 #freedesktop: < bentiss> yeah, that's is too bad, but yeah 14:59 -!- rasterman [~rasterman@cpc99584-brnt1-2-0-cust1380.4-2.cable.virginm.net] has joined #dri-devel 14:59 -!- rasterman [~rasterman@cpc99584-brnt1-2-0-cust1380.4-2.cable.virginm.net] has joined #wayland 15:00 -!- mmu_man [~revol@188410969.box.freepro.com] has quit [Ping timeout: 480 seconds] 15:03 -!- fab [~fab@134.214.236.142] has quit [Quit: fab] 15:04 #dri-devel: < agd5f> AMD hardware going back to navi1x can do user mode queues for gfx in theory 15:05 #dri-devel: < ishitatsuyuki> but does that imply errata-free? :p 15:13 #dri-devel: < MrCooper> Lyude: FYI, https://gitlab.freedesktop.org/drm/amd/-/issues/2171#note_1734122 and its grand-parent comment indicate hwentlan's series doesn't fully fix the MST regressions 15:19 -!- sparky4 [~sparky4@hutcheson-192.resnet.latech.edu] has quit [Ping timeout: 480 seconds] 15:20 -!- mmu_man [~revol@82-65-227-82.subs.proxad.net] has joined #nouveau 15:21 -!- alarumbe [~lrmb@82-69-11-11.dsl.in-addr.zen.co.uk] has joined #dri-devel 15:21 -!- alarumbe [~lrmb@82-69-11-11.dsl.in-addr.zen.co.uk] has joined #etnaviv 15:21 -!- alarumbe [~lrmb@82-69-11-11.dsl.in-addr.zen.co.uk] has joined #intel-gfx 15:21 -!- alarumbe [~lrmb@82-69-11-11.dsl.in-addr.zen.co.uk] has joined #radeon 15:21 -!- alarumbe [~lrmb@82-69-11-11.dsl.in-addr.zen.co.uk] has joined #wayland 15:35 -!- ximion [~ximion@ip-176-199-211-178.um44.pools.vodafone-ip.de] has joined #freedesktop 15:35 #dri-devel: < nroberts> are there any plans to make meson support generating the rustdoc documetation? 15:35 -!- greenjustin_ is now known as greenjustin 15:42 -!- sparky4 [~sparky4@wireless-c-1758.LaTech.edu] has joined #nouveau 15:46 -!- manuel_ [~manuel198@62.99.131.178] has joined #wayland 15:52 -!- manuel1985 [~manuel198@62.99.131.178] has quit [Ping timeout: 480 seconds] 16:03 -!- ybogdano [~ybogdano@134.134.137.86] has joined #freedesktop 16:03 -!- ybogdano [~ybogdano@134.134.137.86] has joined #intel-gfx 16:03 -!- ybogdano [~ybogdano@134.134.137.86] has joined #intel-3d 16:03 -!- ybogdano [~ybogdano@134.134.137.86] has joined #dri-devel 16:03 -!- ybogdano [~ybogdano@134.134.137.86] has joined #wayland 16:04 -!- Hazematman [~lfryzekig@2001:470:1af1:101::1:194] has joined #freedesktop 16:04 -!- Hazematman [~lfryzekig@2001:470:1af1:101::1:194] has left #freedesktop [] 16:05 -!- sgruszka [~sgruszka@134.191.220.81] has quit [Remote host closed the connection] 16:05 -!- Hazematman [~lfryzekig@2001:470:1af1:101::1:194] has joined #freedesktop 16:08 -!- fab [~fab@bellet.info] has joined #dri-devel 16:10 -!- Hazematman [~lfryzekig@2001:470:1af1:101::1:194] has left #freedesktop [] 16:13 -!- jewins [~Thunderbi@192.55.54.53] has quit [Ping timeout: 480 seconds] 16:13 -!- jewins [~Thunderbi@192.55.54.53] has quit [Ping timeout: 480 seconds] 16:13 -!- jewins [~Thunderbi@192.55.54.53] has quit [Ping timeout: 480 seconds] 16:15 #dri-devel: < DavidHeidelberg[m]> going to merge kernel uprev from 6.0 to 6.1, any objections? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20855 16:16 -!- pochu [~pochu@87.red-88-30-59.staticip.rima-tde.net] has quit [] 16:16 -!- pochu [~pochu@87.red-88-30-59.staticip.rima-tde.net] has quit [] 16:16 #dri-devel: < DavidHeidelberg[m]> Sergi stress-tested it a lot; I also gave it a few runs, so stability turned out to be good. 16:20 -!- natto [~natto@140.238.225.67] has quit [] 16:21 #etnaviv: < tomeu> austriancoder: for when you are back, I'm wondering about the meaning of irnd in f2irnd 16:21 -!- kzd [~kzd@static-198-54-130-100.cust.tzulo.com] has joined #radeon 16:21 -!- kzd [~kzd@static-198-54-130-100.cust.tzulo.com] has joined #dri-devel 16:22 #dri-devel: < agd5f> what we did to support implicit sync is to add a new secure semaphore packet which you put into the user mode queue. UMD tells the KMD what ring write pointer value is for the user queue associated with the implicit sync. The new secure packet then writes the wptr value to a location in the KMD's GPU address space. KMD can then use that value to sync against when it needs to. That memory can also be mapped RO into the GPU address space of 16:22 #dri-devel: < agd5f> other processes and they can use wait packets to sync against 16:23 -!- natto [~natto@140.238.225.67] has joined #dri-devel 16:23 -!- jarthur [~jarthur@2603-8080-1500-1a3e-8d77-943a-4c72-7654.res6.spectrum.com] has joined #freedesktop 16:23 -!- jarthur [~jarthur@2603-8080-1500-1a3e-8d77-943a-4c72-7654.res6.spectrum.com] has joined #radeon 16:30 -!- fab [~fab@bellet.info] has quit [Read error: No route to host] 16:34 -!- boqun [~fixme@2001:4898:80e8:36:ad1e:f22f:e1b7:ada2] has joined #dri-devel 16:36 -!- pochu [~pochu@87.red-88-30-59.staticip.rima-tde.net] has joined #wayland 16:36 -!- pochu [~pochu@87.red-88-30-59.staticip.rima-tde.net] has joined #dri-devel 16:36 -!- fjdegroo [~fjdegroo@134.134.139.87] has joined #intel-3d 16:40 -!- rv1sr [~rv1sr@0002da44.user.oftc.net] has joined #wayland 16:42 #dri-devel: < LaserEyess> agd5f: is there any circumstances where the driver, given access to PIXEL_ENCODING_RGB *should* not use that? Assuming, of course, the display supports it 16:43 #dri-devel: < LaserEyess> for example 16:43 #dri-devel: < LaserEyess> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L5229 16:43 #dri-devel: < LaserEyess> shouldn't these checks on YCRCB444 and RGB be reversed? 16:43 -!- jewins [~Thunderbi@192.55.54.53] has joined #intel-gfx 16:43 -!- jewins [~Thunderbi@192.55.54.53] has joined #dri-devel 16:43 -!- jewins [~Thunderbi@192.55.54.53] has joined #intel-3d 16:43 #dri-devel: < LaserEyess> if it *cannot* use it, I understand, but I don't understand why RGB wouldn't be preferred here 16:44 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Remote host closed the connection] 16:44 -!- frieder [~frieder@i4DF677E2.static.tripleplugandplay.com] has quit [Remote host closed the connection] 16:49 -!- fab [~fab@bellet.info] has joined #dri-devel 16:49 -!- jsa [~jsaarine@134.191.220.83] has quit [Read error: Connection reset by peer] 16:49 -!- bgs [~bgs@212-85-160-171.dynamic.telemach.net] has joined #dri-devel 16:52 -!- drod [~ldm@ip-95-220-72-20.bb.netbynet.ru] has joined #lima 16:53 -!- sparky4 [~sparky4@wireless-c-1758.LaTech.edu] has quit [Ping timeout: 480 seconds] 16:56 -!- fab [~fab@bellet.info] has quit [Read error: No route to host] 16:56 #dri-devel: < danvet> MrCooper, it can't prevent that right now for most drivers either, you'd need a cmd parser to make sure userspace didn't sneak in a wait-before-submit 16:57 #dri-devel: < danvet> so all we really need is an uapi contract that userspace must not do that, and the pieces I listed on the kernel side to make sure the resulting dma_fence don't break any rules 16:57 #dri-devel: < danvet> if userspace breaks the contract it gets to keep the pieces 16:57 #dri-devel: < danvet> which results in garbage rendered into that buffer 16:57 #dri-devel: < danvet> which userspace can do anyway if it feels like 16:57 #wayland: < wlb> wayland-protocols Merge request !188 opened by Simon Ser (emersion) xdg-shell: forbid ack_configure with unmapped surface https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/188 [xdg-shell] 16:58 -!- nckncknck [~freeman@broadband-37-110-50-132.ip.moscow.rt.ru] has left #nouveau [] 17:00 #dri-devel: < danvet> agd5f, I still think not even that was really necessary 17:00 #dri-devel: < danvet> you can also kmap that page and leave it in the gpu va to write into 17:01 #dri-devel: < danvet> and then have a little bit of validation on the kernel side to make sure the fence timeline doesn't walk backwards 17:01 #dri-devel: < agd5f> LaserEyess, not sure. question for hwentlan 17:02 #dri-devel: < agd5f> danvet, yeah, it just guarantees a monotonically increasing value 17:02 #dri-devel: < LaserEyess> ok thanks 17:02 #dri-devel: < danvet> agd5f, oh the secure write is an rmw cycle to make sure it's only ever going up? 17:03 #dri-devel: < danvet> still needs a bunch of kernel code to make sure the timeout&ctx nuking happens, but I guess you can in some cases consume them directly somewhere else 17:03 #dri-devel: < MrCooper> danvet: so if there is explicit sync in the display protocol, and user space is silly enough to attempt wait-before-signal, it may appear to work fine most of the time? 17:04 #dri-devel: < danvet> MrCooper, yeah 17:04 #dri-devel: < danvet> well, wait-before-sync even works nowadays most of the time 17:04 #wayland: < wlb> wayland-protocols/main: Simon Ser * Add merge request template for new protocols https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/1dbb67337344 .gitlab/merge_request_templates/New protocol.md 17:04 #wayland: < wlb> wayland-protocols Merge request !179 merged \o/ (Add merge request template for new protocols https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/179) 17:04 #dri-devel: < danvet> until you stack things deep enough and run out of luck at the right time 17:05 #dri-devel: < danvet> you don't really need a protocol to shovel them around, between engines/context in one process is good enough 17:05 #dri-devel: < danvet> or just engine/cpu 17:05 #dri-devel: < danvet> which vk allows 17:06 #dri-devel: < MrCooper> well, this is specifically about wait-before-signal drawing to a BO shared between a client and a display server 17:06 #dri-devel: < danvet> it's just wait-before-signal 17:06 #dri-devel: < danvet> no further conditions needed to go boom 17:07 #wayland: < wlb> wayland-protocols Merge request !153 closed (color-representation: new protocol) 17:07 #dri-devel: < MrCooper> I'm afraid I'm also starting to get more confused than I was when I started asking questions this morning :/ 17:07 #wayland: < wlb> wayland-protocols/main: Xaver Hugl * staging/drm-lease: clarify connector naming https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/930bc8014b43 staging/drm-lease/drm-lease-v1.xml 17:07 #wayland: < wlb> wayland-protocols Merge request !181 merged \o/ (staging/drm-lease: clarify connector naming https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/181) 17:09 #dri-devel: < danvet> so the problem is that if you do wait before signal using dma-fence, then that fundamentally deadlocks 17:09 #dri-devel: < danvet> so you need to unwind it in userspace and do the entire drm_syncobj fence materialization dance 17:09 #dri-devel: < danvet> which mostly works, except protocols 17:09 #dri-devel: < danvet> and it's also a mess 17:10 #dri-devel: < danvet> but nothing is stopping userspace from just ignoring all these rules, and happily mixing wait-before-signal and dma_fence 17:10 #dri-devel: < danvet> and it will mostly work 17:10 #dri-devel: < danvet> even under memory pressure 17:10 #dri-devel: < danvet> until your luck works out 17:10 #dri-devel: < danvet> *runs out 17:10 #dri-devel: < danvet> so the protocol thing isn't really fundamental, it just forces these various gaps and mismatch more clearly into the light 17:15 -!- fab [~fab@bellet.info] has joined #dri-devel 17:16 -!- bvivekan__ [~bvivekan@192.55.79.173] has quit [Remote host closed the connection] 17:17 -!- bvivekan__ [~bvivekan@122.166.101.63] has joined #intel-gfx 17:23 #nouveau: < fdobridge> I think it might be blob RE time. 17:23 #nouveau: < fdobridge> Unless @karolherbst🐧 wants to tell me how FSET (with a float destinaion, not a predicate) works. 17:23 #wayland: < zamundaaa[m]> jadahl: can you have a look at the wl_keyboard MR again? 17:24 #wayland: < jadahl> zamundaaa[m]: can you link me? 17:24 #wayland: < zamundaaa[m]> https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/259 17:24 #nouveau: < fdobridge> Oh, maybe that's FSET_BF in codegen. 17:25 #wayland: < jadahl> thanks 17:28 -!- gawin [~filip@0002cee1.user.oftc.net] has joined #dri-devel 17:29 -!- molinari [~molinari@176-172-98-151.abo.bbox.fr] has quit [Ping timeout: 480 seconds] 17:37 -!- iive [~iive@87.119.101.204.client.entry.bg] has joined #dri-devel 17:37 -!- iive [~iive@87.119.101.204.client.entry.bg] has joined #radeon 17:37 -!- iive [~iive@87.119.101.204.client.entry.bg] has joined #d3d9 17:44 -!- sparky4 [~sparky4@138.47.241.192] has joined #nouveau 17:45 -!- devilhorns [~devilhorn@2601:80:c980:7400::f1d5] has quit [] 17:45 -!- devilhorns [~devilhorn@2601:80:c980:7400::f1d5] has quit [] 17:47 -!- lynxeye [~lynxeye@2a02:560:5898:3f00:20e1:7881:a58b:630d] has quit [Quit: Leaving.] 17:47 -!- lynxeye [~lynxeye@2a02:560:5898:3f00:20e1:7881:a58b:630d] has quit [Quit: Leaving.] 17:49 -!- MajorBiscuit [~MajorBisc@145.94.182.137] has quit [Ping timeout: 480 seconds] 17:49 -!- MajorBiscuit [~MajorBisc@145.94.182.137] has quit [Ping timeout: 480 seconds] 17:49 -!- MajorBiscuit [~MajorBisc@145.94.182.137] has quit [Ping timeout: 480 seconds] 17:49 -!- MajorBiscuit [~MajorBisc@145.94.182.137] has quit [Ping timeout: 480 seconds] 17:49 -!- MajorBiscuit [~MajorBisc@145.94.182.137] has quit [Ping timeout: 480 seconds] 17:49 -!- MajorBiscuit [~MajorBisc@145.94.182.137] has quit [Ping timeout: 480 seconds] 17:51 -!- kem [~kem@cpe-98-26-110-213.nc.res.rr.com] has joined #freedesktop 17:51 -!- kem [~kem@cpe-98-26-110-213.nc.res.rr.com] has joined #dri-devel 18:00 -!- tursulin [~tursulin@134.191.227.52] has quit [Ping timeout: 480 seconds] 18:00 -!- tursulin [~tursulin@134.191.227.52] has quit [Ping timeout: 480 seconds] 18:00 -!- tursulin [~tursulin@134.191.227.52] has quit [Ping timeout: 480 seconds] 18:03 -!- Szadek [~Szadek@185.254.75.49] has quit [Quit: WeeChat 3.8] 18:06 -!- Szadek [~Szadek@194.36.25.55] has joined #wayland 18:07 -!- Kruppt [~Kruppt@104.169.45.179] has quit [] 18:09 #wayland: < bl4ckb0ne> pq: it's a whole mess, between how openxr processes a frame and polling the input events, so far the solution of shoving that in a thread and having wayland polling events on the main thread seems fine 18:10 #wayland: < bl4ckb0ne> got the same advice in #monado eh 18:16 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #freedesktop 18:16 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #radeon 18:16 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #wayland 18:17 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [] 18:17 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [] 18:17 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [] 18:19 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #freedesktop 18:19 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #radeon 18:19 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #wayland 18:20 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [] 18:20 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [] 18:20 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [] 18:22 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #freedesktop 18:22 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #wayland 18:22 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #radeon 18:23 #wayland: < wlb> wayland-protocols Merge request !188 closed (xdg-shell: forbid ack_configure with unmapped surface) 18:27 #freedreno: < Marijn[m]> Oh nice, the DP DSC feature arrived on the lists 🎉 - time to see if anything is salvageable for DSI 18:28 #freedreno: < Marijn[m]> And that leads me to the typical nitty questions (that should have just been addressed before this was sent): what's the right tag for dpu, with disp/, and as /dpu or /dpu1? Seeing many different formats, even within this series... 18:29 #nouveau: < fdobridge> same as a normal set? 18:29 #nouveau: < fdobridge> just you write into a register 18:29 #nouveau: < fdobridge> 1.0 us true and 0.0 is false 18:30 #nouveau: < fdobridge> I think 18:30 -!- pochu [~pochu@87.red-88-30-59.staticip.rima-tde.net] has quit [] 18:30 -!- pochu [~pochu@87.red-88-30-59.staticip.rima-tde.net] has quit [] 18:30 #nouveau: < fdobridge> well anything except 0.0 is true, but for the output 18:31 -!- miracolix [~snuckls@p4fd1ad0e.dip0.t-ipconnect.de] has joined #freedesktop 18:39 #radeon: < colo> booting up, Linux 6.1 complains about [ 0.275259] pci 0000:06:00.0: 126.016 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x16 link at 0000:00:08.1 (capable of 252.048 Gb/s with 16.0 GT/s PCIe x16 link) 18:39 #radeon: < colo> I have this device at that bus address: 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus [1022:1635] 18:40 -!- Szadek [~Szadek@194.36.25.55] has quit [Ping timeout: 480 seconds] 18:41 #radeon: < colo> I have a Zen2 APU on a B550 board, and two questions regarding this ;) 1.) will this limit iGPU or general system performance? 2.) is this a BIOS/firmware/configuration issue, or a hardware limitation of my mainboard? 18:41 #radeon: < colo> ... and for completeness' sake: 06:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Renoir [1002:1636] (rev d9) 18:41 -!- Szadek [~Szadek@169.150.201.18] has joined #wayland 18:46 -!- JohnnyonFlame [~quassel@189-84-181-215.zamix.com.br] has joined #etnaviv 18:46 -!- JohnnyonFlame [~quassel@189-84-181-215.zamix.com.br] has joined #dri-devel 18:48 -!- djbw [~djbw@192.55.54.54] has joined #dri-devel 18:49 -!- DodoGTA [~DodoGTA@5.20.104.245] has joined #wayland 18:49 -!- DodoGTA [~DodoGTA@5.20.104.245] has joined #nouveau 18:50 #freedreno: < abhinav__> Marijn[m] the DSC 1.2 calculations are entirely re-usable if the panel bits are hooked up correctly. Thats what jessica_24 is doing at the moment with the sm8350 panel. Tag depends on the files which the patch is touching ofcourse. But for DPU files, we have been using drm/msm/dpu . If you dont see that, please drop a comment for the author to fix 18:51 #freedreno: < Marijn[m]> abhinav__: thanks, already dropped a comment on that 18:51 #freedreno: < Marijn[m]> I'm just scrolling through the series, and, to put it lightly... I have no idea where to even begin. 18:51 #freedreno: < Marijn[m]> Sorry :( 18:52 #freedreno: < abhinav__> yeah its a pretty big one, even i havent spent too much time reviewing the patches aside from helping kuogee with some of the bugs he was facing 18:57 #nouveau: < fdobridge> No, they're different opcodes 18:57 #nouveau: < fdobridge> But I got it 18:58 #nouveau: < fdobridge> I think I'm far enough along that I can implement source modifier propagation next. 😁 18:58 #nouveau: < fdobridge> Then start on a legalization pass 18:58 #nouveau: < fdobridge> I should do control flow soon... 🤔 18:59 #dri-devel: < agd5f> danvet, yeah the write pointer is a 64 bit monotonic number since vega 19:00 #radeon: < agd5f> colo, what device is being limited? The iGPU doesn't connect via PCIe so it's irrelevant 19:00 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has joined #dri-devel 19:01 #nouveau: < fdobridge> right.. but I meant the semantics are similar/same, no? 19:02 #dri-devel: < DemiMarie> bnieuwenhuizen emersion: I strongly recommend not waiting on UMF 19:04 #radeon: < colo> agd5f: I don't have any empirical observations except for this warning :) it just gave me a reason to wonder if there's something set up in a less than ideal way and that I could maybe do something about it. full PCI bus listing is here: https://coloss.us.to/lscpi_202301 19:05 #intel-gfx: < mdnavare> vsyrjala: I am making changes to the VRR compute config so that we always compute the VRR parameters irrespective of whether userspace has requested VRR with vrr-enable prop, and then in commit is when we will check for VRR enable if requested only then we set the vrr enable bit and push 19:06 #intel-gfx: < mdnavare> vsyrjala: Does that sound like a good approach to start sending my code changes out for review? 19:06 #dri-devel: < DemiMarie> danvet: is the problem that dma-fence is a terrible API? 19:09 -!- Kayden [~kwg@50.39.173.82] has quit [Quit: to the office, where the computers are not, nor are the radio signals] 19:09 -!- Kayden [~kwg@50.39.173.82] has quit [Quit: to the office, where the computers are not, nor are the radio signals] 19:09 -!- Kayden [~kwg@50.39.173.82] has quit [Quit: to the office, where the computers are not, nor are the radio signals] 19:09 -!- Kayden [~kwg@50.39.173.82] has quit [Quit: to the office, where the computers are not, nor are the radio signals] 19:12 -!- agd5f_ [~agd5f@244.sub-174-206-34.myvzw.com] has joined #freedesktop 19:12 -!- agd5f_ [~agd5f@244.sub-174-206-34.myvzw.com] has joined #wayland 19:12 -!- agd5f_ [~agd5f@244.sub-174-206-34.myvzw.com] has joined #intel-gfx 19:12 -!- agd5f_ [~agd5f@244.sub-174-206-34.myvzw.com] has joined #intel-3d 19:12 -!- agd5f_ [~agd5f@244.sub-174-206-34.myvzw.com] has joined #nouveau 19:12 -!- agd5f_ [~agd5f@244.sub-174-206-34.myvzw.com] has joined #radeon 19:12 -!- agd5f_ [~agd5f@244.sub-174-206-34.myvzw.com] has joined #dri-devel 19:16 #nouveau: < KungFuJesus> karolherbst: Compiler bug is _not_ where I expected that one to land at, heh 19:18 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 19:18 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 19:18 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 19:18 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 19:18 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 19:18 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 19:18 -!- agd5f [~agd5f@0001329f.user.oftc.net] has quit [Ping timeout: 480 seconds] 19:19 #radeon: < colo> agd5f_: in case you missed that due to your timeout - I don't have any empirical observations except for this warning :) it just gave me a reason to wonder if there's something set up in a less than ideal way and that I could maybe do something about it. full PCI bus listing is here: https://coloss.us.to/lscpi_202301 19:30 -!- kts [~kts@103.73.237.98] has quit [Quit: Leaving] 19:30 -!- kts [~kts@103.73.237.98] has quit [Quit: Leaving] 19:30 -!- kts [~kts@103.73.237.98] has quit [Quit: Leaving] 19:30 -!- kts [~kts@103.73.237.98] has quit [Quit: Leaving] 19:32 -!- Kayden [~kwg@134.134.139.71] has joined #intel-gfx 19:32 -!- Kayden [~kwg@134.134.139.71] has joined #intel-3d 19:32 -!- Kayden [~kwg@134.134.139.71] has joined #dri-devel 19:32 -!- Kayden [~kwg@134.134.139.71] has joined #freedesktop 19:32 -!- jgrulich [~jgrulich@dynamic-2a00-1028-9942-709e-ddf9-9ddc-36fb-0830.ipv6.o2.cz] has quit [Ping timeout: 480 seconds] 19:34 -!- ngcortes [~ngcortes@134.134.139.84] has joined #intel-3d 19:34 -!- ngcortes [~ngcortes@134.134.139.84] has joined #intel-gfx 19:34 -!- ngcortes [~ngcortes@134.134.139.84] has joined #dri-devel 19:34 -!- agd5f_ [~agd5f@244.sub-174-206-34.myvzw.com] has quit [] 19:34 -!- agd5f_ [~agd5f@244.sub-174-206-34.myvzw.com] has quit [] 19:34 -!- agd5f_ [~agd5f@244.sub-174-206-34.myvzw.com] has quit [] 19:34 -!- agd5f_ [~agd5f@244.sub-174-206-34.myvzw.com] has quit [] 19:34 -!- agd5f_ [~agd5f@244.sub-174-206-34.myvzw.com] has quit [] 19:34 -!- agd5f_ [~agd5f@244.sub-174-206-34.myvzw.com] has quit [] 19:34 -!- agd5f_ [~agd5f@244.sub-174-206-34.myvzw.com] has quit [] 19:35 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #dri-devel 19:35 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #radeon 19:35 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #nouveau 19:35 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #intel-3d 19:35 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #intel-gfx 19:35 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #wayland 19:35 -!- agd5f [~agd5f@0001329f.user.oftc.net] has joined #freedesktop 19:38 -!- chewitt [~chewitt@0002b8dc.user.oftc.net] has quit [Quit: Zzz..] 19:38 -!- chewitt [~chewitt@0002b8dc.user.oftc.net] has quit [Quit: Zzz..] 19:44 #dri-devel: < airlied> dj-death: testing on my dg2 throws up a tiling error, since the engine wants Y tiling will have to figure out what it wants on dg2 19:50 -!- molinari [~molinari@176-172-98-151.abo.bbox.fr] has joined #wayland 19:53 -!- bvivekan__ [~bvivekan@122.166.101.63] has quit [Remote host closed the connection] 19:53 -!- bvivekan__ [~bvivekan@122.166.101.63] has joined #intel-gfx 19:55 -!- vliaskov [~vliaskov@dynamic-078-054-160-047.78.54.pool.telefonica.de] has quit [] 19:55 -!- vliaskov [~vliaskov@dynamic-078-054-160-047.78.54.pool.telefonica.de] has quit [] 20:02 -!- lemonzest [~lemonzest@cpc86080-nott19-2-0-cust160.12-2.cable.virginm.net] has quit [Quit: WeeChat 3.6] 20:02 -!- lemonzest [~lemonzest@cpc86080-nott19-2-0-cust160.12-2.cable.virginm.net] has quit [Quit: WeeChat 3.6] 20:05 -!- rmckeever [~rmckeever@209-172-31-172.heliobroadband.com] has joined #dri-devel 20:05 -!- rmckeever [~rmckeever@209-172-31-172.heliobroadband.com] has joined #nouveau 20:05 -!- gouchi [~gouchi@78.196.21.187] has joined #dri-devel 20:07 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has quit [Ping timeout: 480 seconds] 20:08 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:88ec:68fb:7bf2:c8c0] has quit [Quit: Leaving] 20:08 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:88ec:68fb:7bf2:c8c0] has quit [Quit: Leaving] 20:08 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:88ec:68fb:7bf2:c8c0] has quit [Quit: Leaving] 20:08 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:88ec:68fb:7bf2:c8c0] has quit [Quit: Leaving] 20:08 -!- tzimmermann [~tzimmerma@2001:9e8:21fc:5700:88ec:68fb:7bf2:c8c0] has quit [Quit: Leaving] 20:11 -!- ybogdano [~ybogdano@134.134.137.86] has quit [Ping timeout: 480 seconds] 20:11 -!- ybogdano [~ybogdano@134.134.137.86] has quit [Ping timeout: 480 seconds] 20:11 -!- ybogdano [~ybogdano@134.134.137.86] has quit [Ping timeout: 480 seconds] 20:11 -!- ybogdano [~ybogdano@134.134.137.86] has quit [Ping timeout: 480 seconds] 20:11 -!- ybogdano [~ybogdano@134.134.137.86] has quit [Ping timeout: 480 seconds] 20:13 -!- bgs [~bgs@212-85-160-171.dynamic.telemach.net] has quit [Remote host closed the connection] 20:18 -!- mvlad [~mvlad@2a02:2f08:470d:8800:24d7:51ff:fed6:906d] has quit [Remote host closed the connection] 20:18 -!- mvlad [~mvlad@2a02:2f08:470d:8800:24d7:51ff:fed6:906d] has quit [Remote host closed the connection] 20:18 -!- mvlad [~mvlad@2a02:2f08:470d:8800:24d7:51ff:fed6:906d] has quit [Remote host closed the connection] 20:18 -!- mvlad [~mvlad@2a02:2f08:470d:8800:24d7:51ff:fed6:906d] has quit [Remote host closed the connection] 20:21 -!- rv1sr [~rv1sr@0002da44.user.oftc.net] has quit [] 20:23 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has joined #dri-devel 20:31 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #dri-devel 20:31 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #wayland 20:31 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has joined #radeon 20:43 #freedreno: < Marijn[m]> abhinav__: it's not just big, but I'll let the review do the talking... 20:44 #freedreno: < Marijn[m]> abhinav__: for one it's blindly copying broken downstream code over my fixes, without considering different kinds of values being used on mainline... 20:45 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has quit [Quit: Ex-Chat] 20:45 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has quit [Quit: Ex-Chat] 20:45 -!- Haaninjo [~anders@0001ac70.user.oftc.net] has quit [Quit: Ex-Chat] 20:46 -!- Mangix [~quassel@c-98-35-106-243.hsd1.ca.comcast.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 20:46 -!- Mangix [~quassel@c-98-35-106-243.hsd1.ca.comcast.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 20:46 -!- Mangix [~quassel@c-98-35-106-243.hsd1.ca.comcast.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 20:47 -!- Mangix [~quassel@c-98-35-106-243.hsd1.ca.comcast.net] has joined #nouveau 20:47 -!- Mangix [~quassel@c-98-35-106-243.hsd1.ca.comcast.net] has joined #radeon 20:47 -!- Mangix [~quassel@c-98-35-106-243.hsd1.ca.comcast.net] has joined #dri-devel 20:52 -!- fmuellner [~fmuellner@78.30.26.40] has quit [Ping timeout: 480 seconds] 20:53 -!- Szadek [~Szadek@169.150.201.18] has quit [Quit: WeeChat 3.8] 20:55 -!- ricotz [~ricotz@155.133.217.57] has quit [Quit: Leaving] 20:59 #freedreno: < lumag> abhinav__, please, don't push for the PSR. Too late IMO. 21:00 -!- srslypascal [~srslypasc@0002bff5.user.oftc.net] has quit [Ping timeout: 480 seconds] 21:01 -!- gawin [~filip@0002cee1.user.oftc.net] has quit [Ping timeout: 480 seconds] 21:04 #wayland: < wlb> wayland Issue #348 opened by Xaver Hugl (Zamundaaa) Differences in axis values between compositors https://gitlab.freedesktop.org/wayland/wayland/-/issues/348 21:04 -!- libv_ [~libv@2001:a62:1585:da10:d250:99ff:feae:5ee] has joined #dri-devel 21:05 #etnaviv: < austriancoder> tomeu: I figured out most of the endcodings for img_load, img_store, img_load_3d and img_store_3d opcodes .. will push a doc update tomorrow 21:05 -!- DynamiteDan [sid422602@id-422602.lymington.irccloud.com] has joined #intel-3d 21:05 #etnaviv: < austriancoder> tomeu: f2irnd should be float to integer conversion with rounding 21:06 #etnaviv: * austriancoder bed time 21:06 -!- libv [~libv@2001:a62:1587:3110:d250:99ff:feae:5ee] has quit [Ping timeout: 480 seconds] 21:07 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Ping timeout: 480 seconds] 21:07 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Ping timeout: 480 seconds] 21:07 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Ping timeout: 480 seconds] 21:08 -!- Deluxef [~Deluxe@212.4.150.151] has quit [Remote host closed the connection] 21:13 #intel-3d: < dcbaker> dj-death: You noted that 6f02f9d1084087c97005815bb6070053d09a422c (anv: fix preemption enable emission in gpu_memcpy) is a Fix that's nominated for 23.0, but I'm not sure how it applies unless I also pull in 9a16effeac8cc808745729ab617869c2 ( anv: record secondaries' traces into primaries). What would you like to do? 21:15 -!- jluthra [~darkapex@0002cf79.user.oftc.net] has quit [Remote host closed the connection] 21:16 -!- jluthra [~darkapex@0002cf79.user.oftc.net] has joined #dri-devel 21:23 -!- dcz_ [~dcz@dynamic-002-244-055-074.2.244.pool.telefonica.de] has quit [Ping timeout: 480 seconds] 21:24 #dri-devel: < danvet> jekstrand, tilers that allocate more memory while executing a batch 21:25 -!- ice99 [~ice9@kernelone.com] has quit [Ping timeout: 480 seconds] 21:25 -!- ice99 [~ice9@kernelone.com] has quit [Ping timeout: 480 seconds] 21:31 -!- jkrzyszt [~jkrzyszt@134.191.227.56] has quit [Ping timeout: 480 seconds] 21:31 -!- jkrzyszt [~jkrzyszt@134.191.227.56] has quit [Ping timeout: 480 seconds] 21:36 #intel-3d: < dj-death> dcbaker: they're not related 21:37 #intel-3d: < dj-death> dcbaker: it's just that tthe bit moved in 6f02f9d1084087c97005815bb6070053d09a422c has to be moved in the emit_so_memcpy_fini function instead 21:37 #intel-3d: < dj-death> has to be before the MI_BATCH_BUFFER_END 21:47 -!- Szadek [~Szadek@194.36.25.10] has joined #wayland 21:50 #freedreno: < abhinav__> lumag iirc, this week is rc6 .... that gives us 3 more weeks if we land the core bits to drm-misc-next. is that not enough? 21:51 #freedreno: < lumag> abhinav__, ask the dri-devel. However please think it other way around. How much time do you have to unbreak others if it breaks something? 21:51 #freedreno: < robclark> we don't have 3weeks 21:51 #freedreno: < robclark> there is an extra step of merging into drm-next 21:52 -!- hardening [~quassel@arennes-655-1-65-190.w109-218.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 21:52 #intel-3d: < dcbaker> dj-death: okay, I see how that should be backported. Cool, thanks! 21:52 #freedreno: < robclark> PSR is probably too much.. but for stuff that only touches drm/msm there is a bit of time 21:52 -!- aswar002 [~quassel@134.134.139.78] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 21:52 -!- aswar002 [~quassel@134.134.139.78] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 21:52 -!- aswar002 [~quassel@134.134.139.78] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 21:52 -!- aswar002 [~quassel@134.134.139.78] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 21:52 -!- aswar002 [~quassel@134.134.139.78] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 21:53 #intel-3d: < dj-death> dcbaker: thanks 21:53 #intel-3d: < dcbaker> between then genX(emit_apply_pipe_flushes) and anv_batch_emit() calls, right? (just to be sure) 21:53 #freedreno: < lumag> abhinav__, there are a bunch of fixes to be reviewed 21:53 -!- Duke`` [~plop@2a01cb000797780084555bcf152507a7.ipv6.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 21:53 -!- Duke`` [~plop@2a01cb000797780084555bcf152507a7.ipv6.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 21:53 #freedreno: < abhinav__> robclark lumag alright, lets keep it for the next one. Just got a bit excited to land it once i knew we have time till rc8 21:54 -!- sozuba [~sozuba@00028e8f.user.oftc.net] has quit [Ping timeout: 480 seconds] 21:54 #freedreno: < abhinav__> lumag yes I am aware. I am in the middle of some setup pain atm with the chromebooks. Will get to reviews by afternoon hopefully 21:54 #intel-3d: < dcbaker> I'll push the patch in a second 21:55 #freedreno: < lumag> abhinav__, let me repeat that again: we need an immutable branch for core changes, which can be merged into drm-misc/drm-next/whatever and into our msm-next. 21:55 #intel-3d: < dj-death> dcbaker: correct 21:55 #freedreno: < lumag> And such things usually happen early during development cycle 21:56 #freedreno: < lumag> regarding reviews: quite a bad timing. Is there any chance to defer setup to the calm phase of the development cycle? 21:57 #freedreno: < abhinav__> lumag actually I was doing it mostly to setup my sc7280 for the wide planes validation 21:57 #freedreno: < abhinav__> but in the process also decided to upgrade my sc7180, 21:57 #freedreno: < lumag> abhinav__, reviews first ;-) 21:58 #freedreno: < lumag> wideplanes are not going in en mass. But the fixes can 21:58 -!- gouchi [~gouchi@0002b959.user.oftc.net] has quit [Remote host closed the connection] 21:59 #freedreno: < abhinav__> lumag By end of today evening if I dont finish the reviews for the fixes , please yell 21:59 #freedreno: < abhinav__> ;) 21:59 -!- aswar002 [~quassel@134.134.139.78] has joined #intel-3d 21:59 -!- aswar002 [~quassel@134.134.139.78] has joined #dri-devel 21:59 -!- aswar002 [~quassel@134.134.139.78] has joined #freedesktop 21:59 -!- aswar002 [~quassel@134.134.139.78] has joined #intel-gfx 21:59 -!- aswar002 [~quassel@134.134.139.78] has joined #wayland 22:00 #intel-3d: < dcbaker> thanks 22:00 -!- swatish2 [~swatish2@134.134.137.87] has quit [Ping timeout: 480 seconds] 22:03 -!- miracolix [~snuckls@p4fd1ad0e.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 22:05 #dri-devel: < dcbaker> zmike: I had to pull a couple of not-nominated patches to get one of the nominated zink patches to apply. Its the top 3 on the staing/23.0 branch currently, could you let me know if you're okay with that? 22:19 -!- X512 [~vision@softbank126080186102.bbtec.net] has quit [Quit: Vision[]: i've been blurred!] 22:19 -!- X512 [~vision@softbank126080186102.bbtec.net] has quit [Quit: Vision[]: i've been blurred!] 22:20 -!- ybogdano [~ybogdano@134.134.139.87] has joined #freedesktop 22:20 -!- ybogdano [~ybogdano@134.134.139.87] has joined #intel-gfx 22:20 -!- hogander [~jhogande@134.191.220.81] has quit [Read error: Connection reset by peer] 22:20 -!- ybogdano [~ybogdano@134.134.139.87] has joined #intel-3d 22:20 -!- ybogdano [~ybogdano@134.134.139.87] has joined #dri-devel 22:20 -!- ybogdano [~ybogdano@134.134.139.87] has joined #wayland 22:23 #dri-devel: < zmike> dcbaker: whoops, I thought I was on top of conflicts there 22:24 #dri-devel: < zmike> dcbaker: ah yeah, that was originally one patch so the fixes tag didn't get propagated when it was split 22:24 #dri-devel: < zmike> lgtm 22:26 -!- fab [~fab@bellet.info] has quit [Quit: fab] 22:27 -!- sarnex [~sarnex@0002ba23.user.oftc.net] has quit [Quit: Quit] 22:27 -!- sarnex [~sarnex@0002ba23.user.oftc.net] has quit [Quit: Quit] 22:27 -!- sarnex [~sarnex@0002ba23.user.oftc.net] has quit [Quit: Quit] 22:27 -!- sarnex [~sarnex@066-168-117-249.res.spectrum.com] has joined #d3d9 22:27 -!- sarnex [~sarnex@066-168-117-249.res.spectrum.com] has joined #dri-devel 22:27 -!- sarnex [~sarnex@066-168-117-249.res.spectrum.com] has joined #radeon 22:27 -!- orbea [~orbea@000289e2.user.oftc.net] has quit [Remote host closed the connection] 22:27 -!- orbea [~orbea@000289e2.user.oftc.net] has quit [Remote host closed the connection] 22:27 -!- orbea [~orbea@000289e2.user.oftc.net] has quit [Remote host closed the connection] 22:27 -!- orbea [~orbea@000289e2.user.oftc.net] has quit [Remote host closed the connection] 22:28 -!- orbea [~orbea@000289e2.user.oftc.net] has joined #d3d9 22:28 -!- orbea [~orbea@000289e2.user.oftc.net] has joined #dri-devel 22:28 -!- orbea [~orbea@000289e2.user.oftc.net] has joined #nouveau 22:28 -!- orbea [~orbea@000289e2.user.oftc.net] has joined #radeon 22:28 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Ping timeout: 480 seconds] 22:28 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Ping timeout: 480 seconds] 22:28 -!- junaid [~junaid@ip5f59251d.dynamic.kabel-deutschland.de] has quit [Ping timeout: 480 seconds] 22:29 #d3d9: < adavy> DavidHeidelberg[m]: how can I help ? 22:29 #d3d9: < adavy> I haven't worked on piglit before 22:31 #d3d9: < DavidHeidelberg[m]> Well, the piglit part should ve ok, just check the code you originally brought up for xnine still make sense :) 22:31 #d3d9: < DavidHeidelberg[m]> I had to change it a bit and you knoe, I cannot call myself "proud C coder" 22:31 #dri-devel: < jekstrand> danvet: Bad tilers! 22:31 #d3d9: < DavidHeidelberg[m]> *know 22:32 #dri-devel: < danvet> jekstrand, I just realized that maybe I shouldn't think about memory handling deadlocks that much 22:32 #dri-devel: < jekstrand> heh 22:32 #dri-devel: < danvet> I also wonder how many kinda funny-to-buggy drivers we have already 22:32 #dri-devel: < jekstrand> danvet: I'm not aware of any tilers that absolutely have to allocate mid-batch. 22:33 #dri-devel: < zmike> jekstrand: I pinged you on a zink MR, any chance you could take a look in the next couple days 22:33 #dri-devel: < jekstrand> Some of them can go faster if the up a pool size 22:33 #dri-devel: < danvet> jekstrand, hm right, so GFP_NORECLAIM is good enough 22:33 #d3d9: < DavidHeidelberg[m]> adavy: ^ 22:33 -!- gawin [~filip@0002cee1.user.oftc.net] has joined #dri-devel 22:34 #dri-devel: < danvet> I still don't want to read all the drivers to check that :-) 22:34 #d3d9: < DavidHeidelberg[m]> Also in the play is running the code in parallel, but it's fairly quick, so maybe would be safer to keep it in one thread 22:35 -!- fab [~fab@bellet.info] has joined #dri-devel 22:36 #dri-devel: < bnieuwenhuizen> jekstrand: didn't Mali have issues there? (https://community.arm.com/arm-community-blogs/b/graphics-gaming-and-vr-blog/posts/memory-limits-with-vulkan-on-mali-gpus) 22:37 -!- fab [~fab@bellet.info] has quit [] 22:43 #dri-devel: < jekstrand> zmike: translated, more-or-less. 22:43 #dri-devel: < jekstrand> bnieuwenhuizen: On Mali, varying buffers are allocated in userspace 22:43 #dri-devel: < jekstrand> Apple and IMG have a heap that gets allocated by the kernel based on metrics but those can both handle OOM by spilling part-way through the render pass. 22:44 #dri-devel: < jekstrand> So if the kernel goes to allocate and fails, it's ok. It just needs to be careful to not throw the old buffer away until it's sure it has the new one. 22:47 -!- YuGiOhJCJ [~YuGiOhJCJ@00021b1f.user.oftc.net] has joined #dri-devel 22:50 -!- phebus [~phebus@00026109.user.oftc.net] has quit [Quit: POKE 1,0] 22:52 -!- drod [~ldm@ip-95-220-72-20.bb.netbynet.ru] has quit [Remote host closed the connection] 22:52 -!- ngcortes [~ngcortes@134.134.139.84] has quit [Ping timeout: 480 seconds] 22:52 -!- ngcortes [~ngcortes@134.134.139.84] has quit [Ping timeout: 480 seconds] 22:52 -!- ngcortes [~ngcortes@134.134.139.84] has quit [Ping timeout: 480 seconds] 22:53 -!- TMM [hp@amanda.tmm.cx] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 22:53 -!- HerrSpliet [~RSpliet@spliet.org] has joined #dri-devel 22:53 -!- HerrSpliet [~RSpliet@spliet.org] has joined #nouveau 22:54 -!- TMM [hp@amanda.tmm.cx] has joined #dri-devel 22:54 #dri-devel: < danvet> lina, ^^ might also need more GFP_NORECLAIM ... 22:54 -!- RSpliet [~RSpliet@2a01:4b00:86b9:100::c0ff:eeee] has quit [Ping timeout: 480 seconds] 22:54 -!- RSpliet [~RSpliet@2a01:4b00:86b9:100::c0ff:eeee] has quit [Ping timeout: 480 seconds] 22:59 -!- phebus [~phebus@00026109.user.oftc.net] has joined #radeon 23:00 -!- ngcortes [~ngcortes@134.134.139.84] has joined #dri-devel 23:00 -!- ngcortes [~ngcortes@134.134.139.84] has joined #intel-gfx 23:00 -!- ngcortes [~ngcortes@134.134.139.84] has joined #intel-3d 23:04 -!- edrex[m] [~edrexmatr@2001:470:1af1:101::92c3] has left #wayland [] 23:05 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 23:05 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 23:05 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 23:05 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 23:05 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 23:05 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 23:05 -!- danvet [~Daniel@0002b820.user.oftc.net] has quit [Ping timeout: 480 seconds] 23:06 #dri-devel: < zmike> jekstrand: awesome, thanks 23:09 -!- Brainium [~brainium@00028330.user.oftc.net] has joined #radeon 23:09 -!- Brainium [~brainium@00028330.user.oftc.net] has joined #wayland 23:09 -!- Jeremy_Rand_Talos [~Jeremy_Ra@4G4AABXJL.tor-irc.dnsbl.oftc.net] has quit [Remote host closed the connection] 23:09 -!- gawin [~filip@0002cee1.user.oftc.net] has quit [Ping timeout: 480 seconds] 23:10 -!- Jeremy_Rand_Talos [~Jeremy_Ra@7YZAABFVI.tor-irc.dnsbl.oftc.net] has joined #dri-devel 23:16 -!- jdavies__ [~jdavies@165.1.216.62] has joined #dri-devel 23:16 -!- frankbinns1 [~frankbinn@165.1.216.61] has joined #dri-devel 23:16 -!- frankbinns [~frankbinn@66.159.216.5] has quit [Remote host closed the connection] 23:17 -!- jdavies_ [~jdavies@66.159.216.5] has quit [Remote host closed the connection] 23:17 -!- ngcortes [~ngcortes@134.134.139.84] has quit [Ping timeout: 480 seconds] 23:17 -!- ngcortes [~ngcortes@134.134.139.84] has quit [Ping timeout: 480 seconds] 23:17 -!- ngcortes [~ngcortes@134.134.139.84] has quit [Ping timeout: 480 seconds] 23:20 -!- rasterman [~rasterman@cpc99584-brnt1-2-0-cust1380.4-2.cable.virginm.net] has quit [Quit: Gettin' stinky!] 23:20 -!- rasterman [~rasterman@cpc99584-brnt1-2-0-cust1380.4-2.cable.virginm.net] has quit [Quit: Gettin' stinky!] 23:22 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has quit [Quit: dodo] 23:22 -!- pcercuei [~paul@180.pool92-187-99.dynamic.orange.es] has quit [Quit: dodo] 23:22 -!- ngcortes [~ngcortes@134.134.139.84] has joined #dri-devel 23:22 -!- ngcortes [~ngcortes@134.134.139.84] has joined #intel-gfx 23:22 -!- ngcortes [~ngcortes@134.134.139.84] has joined #intel-3d 23:37 -!- sav10 [~sav@177.12.16.193] has joined #wayland 23:43 -!- gawin [~filip@0002cee1.user.oftc.net] has joined #dri-devel 23:46 #dri-devel: < airlied> dj-death: okay dg2 needs some work, once I got past all the missing MOCS, will try and figure that out 23:52 #dri-devel: < dj-death> airlied: thanks 23:57 -!- ngcortes [~ngcortes@134.134.139.84] has quit [Remote host closed the connection] 23:57 -!- ngcortes [~ngcortes@134.134.139.84] has quit [Remote host closed the connection] 23:57 -!- ngcortes [~ngcortes@134.134.139.84] has quit [Remote host closed the connection] 23:57 -!- ngcortes [~ngcortes@134.134.139.84] has joined #dri-devel 23:57 -!- ngcortes [~ngcortes@134.134.139.84] has joined #intel-gfx 23:57 -!- ngcortes [~ngcortes@134.134.139.84] has joined #intel-3d --- Log closed Tue Jan 24 00:00:01 2023