00:23imirkin: hm, looks like there may be something else going on
00:23imirkin: even flipping it to the 2d blitter, i still get the same problem
00:39leidsin1: so having programming concepts that never existed , is similar to estonian making lies composed of situations that happened totally another way around, and those are soon to be taken down, their helth have been interacted with third party people in pesession of some senses of justice and moral, since countries real legal entities charged me over their crimes, but you are going to see their bd run in the future as well as well as their relatives who made
00:39leidsin1: such scam to be legal sanctions against me.
00:40leidsin1: lot of politicians have raised this outlaw corruption in the court allready, so they will get what they diserve soon.
00:43leidsin1: if that was about criminal organizations applying pressure to court of law, then you know chilean president came to powers, a spanish person, he wiped out all such organizations when enterying the throne position.
00:55imirkin: this is very mysterious =/
06:03imirkin: skeggsb: any chance nv50 m2mf might really dislike lines over 64kb in width?
06:03imirkin: having trouble with a rgba32ui 8k wide surface
06:03skeggsb: umm, i'm not sure tbh
06:04imirkin: i know it only supports up to 4x msaa on 128-bit formats
06:05imirkin: i'll try 2d blit
06:05imirkin: that should be the same as m2mf right?
06:06skeggsb: i feel like it *should* be fine for 64kb LINE_LENGTH_IN, but yeah, i guess try a 2d blit and see
06:06imirkin: well, this is 128kb line length
06:06skeggsb: what happens with m2mf when you try?
06:07imirkin: i really should just write my own test program
06:07imirkin: but what i'm seeing is the two "halves" mirrored
06:07imirkin: i.e. line == line
06:07imirkin: but it's a multi-step process
06:07imirkin: first i render to R32UI
06:07imirkin: then there's a (2d) blit to RGBA32UI
06:08imirkin: then we map that texture, which causes a m2mf to a linear surface
06:08imirkin: er, *3d* blit
06:08imirkin: now i'm fairly sure that the 3d blit is fine. i tried to screw around with it, but the mirroring remains
06:09imirkin: so i think it's that final step screwing things up
06:09imirkin: curiously, i tried splitting the m2mf into 2 pieces
06:09imirkin: one for 0..4096
06:09imirkin: and one for 4097..8191
06:09imirkin: er, 0..4095, 4096..8191
06:10imirkin: with that, the second half is just all 0's
06:10imirkin: this is on a G84 in case it matters
06:11imirkin: (G84GL, for that extra crunch)
06:11skeggsb: that all seems rather odd, and i wonder if there's something else messing it up rather than the m2mf
06:11imirkin: definitely a possibility.
06:11skeggsb: easy to test with a simpler program i guess
06:12imirkin: yeah, i really should just do that.
06:12imirkin: a task for tomorrow!
06:12imirkin: i really should make some lib like the ps2 or ps3 or whatever library
06:12imirkin: i guess that's vulkan...
06:12imirkin: but where i can just put cmdbufs together
06:13imirkin: and look at results
06:13imirkin: i guess the shader bit of it is annoying though
06:14imirkin: oh interesting
06:14imirkin: that second variant actually triggers XY_OUT_OF_BOUNDS
06:15imirkin: j'accuse m2mf
06:15imirkin: let's try it in quarters, perhaps my approach is just broken
06:17imirkin: yep, the latter 2 quarters fail
06:17imirkin: i think m2mf just can't go over 64k per line
06:18imirkin: or rather, more than 64k into a line, with arbitrary pitches working fine
06:19skeggsb: kinda odd they didn't throw error-checks into the class if that's the case, buuuuut, definitely plausible
06:21imirkin: works on nvc0, of course
06:21imirkin: actually i guess i dunno
06:21imirkin: i'm comparing to pascal, where we use p2mf
06:21imirkin: or whatever the new hotness is
06:25skeggsb: also known as InlineToMemory
06:26ccr:rubs his head in wonder.
06:26ccr: what's the difference to m2mf?
06:26skeggsb: the source comes from the push buffer rather than memory
06:28imirkin: oh, that's the replacement for sifc. nevermind.
06:28ccr: apparently not mentioned on https://nouveau.freedesktop.org/NouveauTerms.html
06:28imirkin: but we have the copy engine thing
06:28imirkin: i guess g84 has pcrypt... not worth messing with it though
06:29imirkin: unfortunately the blit helpers aren't immediately reusable, i'll work it out tomorrow
06:29imirkin: good night!
10:31Synthea: I have a GeForce 9500 GT, looking at the FeatureMatrix it supports VDPAU hardware acceleration but it requires an external driver. How could I know if such driver is loaded? How could I load it if it's not loaded?
10:31Synthea: And finally how could I know eventual progress towards an opensource replacement?
10:37ccr: not driver, but firmware
10:42RSpliet: Synthea: currently these firmwares are extracted from the official driver. They're not redistributable, so if you're asking whether they are loaded the answer is probably no
10:42RSpliet: You'll have to do that dance yourself
10:43RSpliet: About replacing them with FOSS, I don't think many people have seen the point to that, although obviously nobody is opposed either
10:44RSpliet: I guess like most other efforts we *should* be doing it clean room. E.g. one should reverse-engineer and document the firmware - the interfaces, the algorithms, the functionality. Someone else could then reimplement.
10:45RSpliet: Their ISA is "Falcon", envytools has the means to disassemble these firmwares although some very specialised instructions (the ones seen in video decoding firmware but not the PM or graphics firmware) may be missing
10:45Synthea: RSpliet, but it said it's achieved through official firmware, so how could I link them?
10:45RSpliet: you don't link, they're loaded at run-time
10:46Synthea: RSpliet, which files and how? They're not installed by default
10:46RSpliet: they aren't. The VideoDecoding wiki page has some instructions on how to extract them from NVIDIA's driver
10:55Synthea: RSpliet, https://nouveau.freedesktop.org/VideoAcceleration.html "Note that NV50 below doesn't refer to the family but rather the exact chip. One way to find out which chip you have is by running dmesg | grep -i chipset" doesn't print anything for me
10:57RSpliet: Synthea: yes, looks like that page could do with a few updates. if you just | grep nouveau, you'll see the exact chipset used in the first or second line
11:01Synthea: RSpliet, is nv84_xuc00ff one of these firmware files? It says nouveau tried to load it but failed
12:47damjan: hi all, are consumer questions fine here? I'm not a gamer, I've been looking for a nice graphic card for my Ryzen 5 3600 system. my requirements are at least one hdmi 2.0 and one displayport, possibly silent operation and no frills Linux compatibility
12:49HdkR: Even basic desktopping is sad on Nvidia+Nouveau. You'd be happier with an AMD GPU :)
12:49damjan: in the local pc parts market here, I see some passively cooled GT1030 cards
12:49damjan: HdkR: ok, that was my question. thanks
12:49damjan: sadly I can't find many passively cooled amd cards, but alas, one with a fan that doesn't spin much would be also fine
12:50HdkR: I believe there are a bunch of random OEMs that provide "silent mode" operation where the fan turns off under low load situations
12:50HdkR: Sometimes with a switch on the card to control it
12:52HdkR: https://www.asrock.com/Graphics-Card/AMD/Phantom%20Gaming%20M2%20Radeon%20RX580%208G/index.asp Not a recommendation, but you can see how it has "silent mode" and limits clocks a bit
12:52HdkR: (Only DVI on that card, wtf)
12:58HdkR: https://www.powercolor.com/product?id=1565953800 Newish card with silent switch directly on PCB
12:59HdkR: Completely passive AMD cards are hard/impossible to find
13:01damjan: seems so
13:01damjan: HdkR: thanks. I'll have a look what's available locally
13:48RSpliet: damjan: I second that. Nouveau will not be able to utilise NVIDIA GPUs to the fullest after the first gen Maxwell due to NVIDIAs continued unwillingness to share redistributable firmware files for the power management microcontroller - the one that deals with fan management and DRAM clock speeds.
15:06loonycyborg: I guess they don't make fanless amd cards because all their really weak chips go to APUs :P
15:11RSpliet: NVIDIA didn't do a low-end card in the 2xxx series. They're not out yet for the 3xxx series, if they ever come. Low-to-mid-end GPUs have gone out of fashion since Intel started adding a capable IGP to their processors.
16:07imirkin: RSpliet: VP2 is actually xtensa for the control cpu's
16:07imirkin: falcon didn't become a thing until VP3 (G98)
16:11RSpliet: imirkin: ah! TIL
17:09imirkin: i really wish there was some way to flush totally useless information out of my head, making room for new info
18:14karolherbst: imirkin: write a book
18:16imirkin: will that help remove things from my head?
18:27karolherbst: dunno, never done that
18:27karolherbst: but at least you have it all written down
18:28imirkin: i'm not worried about losing the info. i want to lose the info.
19:13RSpliet: semi off-topic: https://rosenzweig.io/blog/asahi-gpu-part-1.html
21:34imirkin: Lyude: looks like more than a few reports of something modesetting-y getting broken in v5.9
21:34Lyude: imirkin: links?
21:34imirkin: nouveau ML
21:36imirkin: and i think i may have seen some others
21:59Lyude: GF108, was that even able to do 4K?
22:03imirkin: even nv50 can do 4k
22:03imirkin: not if you follow what was advertised though
23:55imirkin: wtf. for the 2d blitter, it appears that we've inverted the linear / block cases in both nv50 and nvc0?!
23:57imirkin: since like 6d1cdec3ba151168bfc3aef222fba6265dfb41fb
23:59imirkin: er wait, nm
23:59imirkin: i'm confused.
23:59imirkin: yeah. i managed to turn myself around.
23:59imirkin: ignore that.