--- 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