00:23 airlied[d]: karolherbst[d]: https://gitlab.freedesktop.org/nouvelles/kernel/-/commits/nouveau-frl-support if you want to play with 144Mhz 🙂
00:24 karolherbst[d]: I'm gonna break it so hard
00:28 karolherbst[d]: mhh not sure if the `nv_connector->type == DCB_CONNECTOR_HDMI_0` part is correct?
00:29 karolherbst[d]: might want to check all the HDMI connector types
00:30 karolherbst[d]: but also for whatever reason `DCB_CONNECTOR_HDMI_0` which is 0x60 is also `0x60 = 3-Pin DIN Stereo Connector ` in the DCB docs 🙃
00:30 airlied[d]: will switch it to the drm one
00:31 airlied[d]: fix is pushed
00:31 karolherbst[d]: yeah.. probably easier
00:32 karolherbst[d]: is HDMI B even a thing still?
00:33 karolherbst[d]: ahh okay so HDMI B still exist with 2.1
00:33 airlied[d]: don't think B ever got into a product though
00:33 karolherbst[d]: mhhhh
00:33 karolherbst[d]: seems to be the faster of the two 🙃
00:34 karolherbst[d]: but yeah...
00:34 airlied[d]: dual-link, but they just jacked up the single lin
00:34 karolherbst[d]: the mini one shows up as HDMI A in DR?
00:34 karolherbst[d]: *DRM
00:35 airlied[d]: yes they are all A I think
00:36 karolherbst[d]: well I'll check tomorrow. My only Turing+ with an actual HDMI port is on a laptop I haven't touched in a while 🥲
00:39 chikuwad[d]: uh, quick question: is there a way I can make this not spawn windows?
00:39 chikuwad[d]: ```deqp-runner run \
00:39 chikuwad[d]: --deqp ~/tools/CTS/deqp-vk-main/external/vulkancts/modules/vulkan/deqp-vk \
00:39 chikuwad[d]: --caselist ~/tools/CTS/VK-GL-CTS/external/vulkancts/mustpass/main/vk-default.txt \
00:39 chikuwad[d]: --output vk-run \
00:39 chikuwad[d]: --env VK_ICD_FILENAMES=/home/sidpr/tools/mesa-staging/share/vulkan/icd.d/nouveau_icd.x86_64.json \
00:39 chikuwad[d]: --env DEQP_VK_DATA_DIR=/home/sidpr/tools/CTS/VK-GL-CTS/vulkan/data \
00:39 chikuwad[d]: --testlog-to-xml ~/tools/CTS-build/executor/testlog-to-xml \
00:39 chikuwad[d]: -- \
00:39 chikuwad[d]: --deqp-log-images=disable \
00:39 chikuwad[d]: --deqp-log-shader-sources=disable \
00:39 chikuwad[d]: --deqp-visibility=hidden
00:43 engineerinreverse: It seems that quadro 4000 RTX's 3D pipeline is rather small, I am entirely confused as to what to make out of this! However cuda cores amount is entirely rare as to being very large amount, so what i thought was cuda cores under Unified shader architecture (or shared shader architecture) can be configured to be shader pipelines under registry so theyd be generic for cuda or 3d shading!
00:49 airlied[d]: chikuwad[d]: don't run any wsi tests 🙂
00:52 engineerinreverse: And the virus at my touchpad has creep back in, which shows pretty expected outcome diagnosed before , that community of shitty engineers you offer in stacks, such as clueless idiots who could not engineer any modern systems based of performance paradigm, are trolling me, youtube kind of points to there, as quantum computers being now even more dangerous, and infinite patterns that we do not know if exist in nature feeds, but anyhow yes if
00:52 engineerinreverse: you break the AES similar to RSA you can self-sign the signature to any software , in other words, user would not know if it had a virus provided the user has not got too much computer knowledge the virus would beat one, since the user is incapable to fix bugs or code in manual or diagnose the real source of the virus, so the wayland firmware bug ramble at sdterr is very unjustified crap, since all the computers firmware is already free such
00:52 engineerinreverse: as open source except the microcode which has zero acpi fw in my case.
00:58 redsheep[d]: airlied[d]: The commit logs make it sound like DSC is also a thing now? Is that only over HDMI or will dsc function on DP too?
00:59 _lyude[d]: DSC will function on DP eventually
00:59 _lyude[d]: it's just not terribly likely to happen in nouveau unless someone puts the work in
00:59 _lyude[d]: it's more likely for nova
01:00 _lyude[d]: but technically speaking - there's nothing stopping anyone from implementing it
01:00 airlied[d]: I think the DSC over HDMI would need more work, but I've no idea how it works
01:53 carlsteigner: now i fixed it again since logs were useful at saying it had picked up /dev/input/mice as the device node, somehow udev isn't working for synaptics driver, so putting a wildcard to matchdevicepath and matchas touchpad fixed it , in the meantime i finished my quantum specification for supercomputation on all worlds hw (though FPGA's perform the best in theory ASICS such as cpus are fine too), but would rather not share any of that work anymore. As
01:53 carlsteigner: many people are asking for trouble from me.
02:32 arielsahadi: I understood that zero states are important, this is a state where the power of two is not included since 388 and 392 are numbers, then the denominator of them is -88-88-88-88=36 and 38 respectively, also -88-88-88-88-88=-52 and -48 and -88-88-88-66 is then 58 and 62, so we make two copies of the root, then 36+36=72 40+40=80 while 58-52=6 and 62-48=14 or we use these constants rather, which give the sequence the difference between 6 and 14 and the
02:32 arielsahadi: next would be 22 or the difference is eight in this way between each power which can be read back, that the sign can be changed as some kind of reference using zero states, for example 72-6=66 80-14=66 you will see that they always give the same result, but if you change the sign to zero using the states, for example, 72--6=78 and 80--14, or 80+14 94, and we get a sequence with differences in the first two numbers 94-78=16 16-digit differences, now
02:32 arielsahadi: we can subtract the maximum using the zero states and then move them from the base, for example, as they were read in to such differences, or if we subtract 12 from the second, the differences are fours as originally, or 94-12=82, only the base is different, or from here we can see that no matter what is taken as a reference, it works if we use the zero states correctly, i.e. 78 94 110 110-16-16=78 94-16=78 78-0=78, or we have to subtract 3*14 from
02:32 arielsahadi: it, which mark the zero states, and the sequence can be read out. or what happened was that we changed the sign using the states out, and subtract yet maximum states off. i did the simplification the twist now soon half a year ago, 110 220 330 440 are being used on azimuths, and decoder encoder uses similar logic, i make a synthesizer for the FPGA's it's gonnabe simple, it only synths bunch of adders ever no block ram such as slice-M will be used, it
02:32 arielsahadi: will delay the memory distribution to 1 clock further/later, so 64luts is one 64bit adder with carry chain propagator per SLICE-L used along for each. It is going to be a quantum computer that you will fight not Estonian or Baltics army forces, my bet is quantum computers will win.
02:43 HdkR: 💃
02:52 armenolerian: pony stalking me and playing a big boss without any brain as a worm will be handled in very neat ways, they beat him entirely up at first to see if that helps we go further down the line with abuse, if it doesn't. Maniac you are a cripple at birth pony.
02:58 armenolerian: what was not handled was 65536 states that have those remainder logic, is two way decoder encoder, mask releases bitcount as zero states and primary value is the denominator ettc. so we process 16bits or more together. However boolean algebra bits are also not explained yet.
02:58 armenolerian: i developed a new boolean algebra, such as on majorana 1 from microsoft
02:58 armenolerian: so i say that showing aggression to me, carries consequences.
02:59 armenolerian: it's just war is boring to me, but when i have to put my chips in i will do so, and make a lot of damage
02:59 armenolerian: however robots do that for being more exact
02:59 armenolerian: that is why it is so boring
03:05 armenolerian: such infinite patterns are in the universe stated to be something like singularity sequences, where as in nature they are called fractals, in biology nucleotide sequences etc so forth
03:39 realslavery: I am working on breaking old encryption methods soon, one of the issues you were always confused about, is prediction vs knowing the outcome -- where the last fixates not predicts through doing things faster, the probability is 100percent in computer systems alike for the outcome, since i orchestrate and manipulate the outcome to be exact as was expectation.
06:51 blisto[d]: 🐸
08:35 everybloom: To say that AI is in child shoes isn't correct, that things happen in 3-10years etc either. Last bits to be implemented takes very few time, i had tested it all already. But to say again that you had anything to do to understand this much or that little yet needed in code, seems to be a lie, cause it's only me who has offered the only solutions to get there, stratix 10 and virtex ultrascale are majorana 1 type quantum performance computers, not
08:35 everybloom: sure what microsoft does technically so not sure if that hardware is as they say and if the phenomenon such as topical qubit required any additional physical engineering.
08:49 everybloom: it's a chaos, too many countries have lethal systems, so let's jump forward to the stack and start to kill each other, cause the genocide that jews commit is just so delicious isn't it?
08:52 everybloom: i have led the systems and research through ancient google for 20years and all others that stole my momentum and health just knew that we have to look at marts solutions cause he get's everything done as always, and we have to humiliate and bother him with disrespect and assaults to frame that we had done all the good but mart was toxic person.
08:53 everybloom: I am thinking as to how such people are allowed to even continue their fraud, totally wrong foot entering.
11:36 mohamexiety[d]: airlied[d]: tried out the patches on my 5060 laptop, but it's not working. monitor is 4k 240Hz HDMI 2.1, cable is HDMI 2.1 as well, but setting anything above 4k 60Hz leads to signal drop
11:37 mohamexiety[d]: without the patches, 60Hz is the maximum, now i can go up to 120Hz which is expected for HDMI 2.1 FRL6, so that part is working
11:37 mohamexiety[d]: but actually setting anything above 60 leads to no signal. dmesg doesnt have anything though :thonk:
11:41 airlied[d]: Can you boot with drm.debug=2 and nouveau.debug=debug?
11:42 airlied[d]: I've only tried on a 3050 so far
11:42 mohamexiety[d]: will do. also i found stuff in journalctl, let me get you a pastebin and will try that
11:43 airlied[d]: If you see any core notifier timeouts then that is bad 🙂
11:46 mohamexiety[d]: https://pastebin.com/KV5Ekvy8
11:47 mohamexiety[d]: will try the debug args now
11:47 airlied[d]: Ah yes core notifier timeout
11:47 airlied[d]: I'll take a look tomorrow, gotta sleep
11:48 mohamexiety[d]: yeah fair enough. good night!
12:10 mohamexiety[d]: oh the debug stuff is _spammy_
12:16 mohamexiety[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1496847152960376913/dmesg.txt?ex=69eb5f0b&is=69ea0d8b&hm=fa68bcbda0661b4acf0b84d43493fca80abe30303a4a0d9132ae20814fbf53b9&
12:16 mohamexiety[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1496847153279139871/journalctldebug.txt?ex=69eb5f0b&is=69ea0d8b&hm=e16443afeffca90dcb15282c329641ae7ed2627ea03036d265ee20c56ddbe4df&
18:06 _lyude[d]: karolherbst[d]: any chance you've got a second? Looking over some of the gem handling code in mesa and I might have found something that smells a bit funny. Specifically, in `nouveau_bo_del()` in `src/gallium/winsys/nouveau/drm/nouveau.c` it seems like we check `nvbo->head.next` before actually grabbing `&nvdev->lock`
18:07 karolherbst[d]: ohh yeah
18:07 karolherbst[d]: that looks like a data race
18:07 _lyude[d]: woooo
18:07 _lyude[d]: maybe that's the one I've been hitting 🙂
18:07 karolherbst[d]: there seem to be more cases
18:07 _lyude[d]: I will write up a patch for it then. Also, do you see any others?
18:07 karolherbst[d]: I mostly copied the code, so not sure I ever changed that
18:09 karolherbst[d]: `nouveau_bo_make_global` and `nouveau_bo_wait` as well I'd say
18:09 karolherbst[d]: mhh
18:09 karolherbst[d]: `nouveau_bo_make_global` might be fine actually
18:09 karolherbst[d]: that's double checked
18:10 karolherbst[d]: but nooooot sure if that still can cause issues
18:11 _lyude[d]: i also did end up actually finding what appears to be a small race in nouveau's kernel module as well, though I'm not terribly convinced it's the one that I'm hittng here (specifically, nouveau_gem_ioctl_info() appears to be missing one of the locks it needs to call nouveau_vma_find(), since at the point of that ioctl the gem object has already been exposed to userspace)
18:12 _lyude[d]: so i guess looking at the vma code wasn't a total loss
18:13 _lyude[d]: gotta go get my hair cut in a bit, so will probably get back to sending out patches/mrs when I get back
18:14 karolherbst[d]: cool, thanks
18:20 mohamexiety[d]: wait does this even matter if we use zink?
18:23 _lyude[d]: mohamexiety[d]: is this replying to me?
18:23 mohamexiety[d]: in general yeah
18:24 _lyude[d]: I don't really know! it's been a while since I've touched mesa honestly
18:24 _lyude[d]: At the same time
18:24 _lyude[d]: I don't see any nouveau ioctls anywhere else in mesa
18:24 _lyude[d]: or at least not GEM_NEW
18:25 _lyude[d]: So, I guess I'd assume it has to be getting used? otherwise I'm not sure how we'd be allocating memory
18:32 mohamexiety[d]: i am not actually sure myself tbh, sorry. there is a separate `src/nouveau/winsys/*` which seems to be what nvk uses but i am not actually sure
18:33 _lyude[d]: Eh it's good, honestly if it's the only ioctl we can find I've gotta assume this is the thing
18:36 marysaka[d]: we do have nouveau_ws_bo_new_tiled_locked using GEM_NEW in `nouveau_bo.c`
18:36 karolherbst[d]: well the old gallium driver is only use pre turing these days
18:36 marysaka[d]: (for NVK side of things)
18:37 _lyude[d]: marysaka[d]: Oh yeah - I meant like, all of the ioctls usages are in that one file
18:37 _lyude[d]: Oh wait
18:37 _lyude[d]: Sorry that is a separate file lol
18:39 mhenning[d]: Yeah, I suspect src/nouveau/winsys is probably what you want to be looking at, although I admit I don't have the clearest idea of how gbm layers over zink
18:41 mohamexiety[d]: yeah for all stuff i had to do that would touch kernel side things i only had to look at `src/nouveau/winsys`, but i dont know if the gallium one comes into play with any compositors or such
18:42 _lyude[d]: Mhhh, it is gnome-shell specifically
18:42 _lyude[d]: So direct gbm being different could make sense
18:50 chikuwad[d]: mhenning[d]: seems like CI failed because we touched all the swap intrinsics
18:52 mhenning[d]: I don't think it's the swap intrinsics specifically - eg in https://gitlab.freedesktop.org/mesa/mesa/-/jobs/98125624 it's complaining about ssbo_atomic
18:54 chikuwad[d]: right
18:54 mhenning[d]: Since all the intrinsics changed we probably just need to set num_components in a few additional places. Validation tells you the pass (eg in that one it's nir_lower_atomics_to_ssbo) which helps identify what needs to be changed
18:54 chikuwad[d]: mhm
18:59 chikuwad[d]: ough
18:59 chikuwad[d]: I'm gonna have to build deqp-gl
18:59 chikuwad[d]: I'll look at this tomorrow
20:25 phomes_[d]: I don't have rights to assign to marge. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40686 should be ready
21:23 _lyude[d]: mhhhh - yeah, it does look like that GBM just goes through zink
21:28 _lyude[d]: I guess I'll just have to run for a while with the gem_info ioctl patch and just hope that was the race condition here
21:33 airlied[d]: I don't think that's an actual race condition though
21:34 _lyude[d]: airlied[d]: oh?
21:34 _lyude[d]: You could be right, since you probably know this code better than I do
21:35 airlied[d]: like you could probably race it with test code designed to race it, but I can't think of a userspace pattern that would do it
21:35 _lyude[d]: yeah :S. kinda why I assumed at first it probably wasn't the right one, but I threw a patch for it into my kernel anyhow
21:35 airlied[d]: if you wrote a test calling info in a tight loop on a gem handle you were allocating, you might get it
21:35 airlied[d]: but I don't think userspace ever calls info on a bo that hasn't been opened
21:36 _lyude[d]: it does i believe, hold on
21:36 airlied[d]: and once a bo is opened it should always have a vma
21:36 _lyude[d]: oh - sorry, I misread "hasn't been opene"
21:36 airlied: in order for a handle to be valid for info it has to be opened
21:37 _lyude[d]: makes sense.
22:05 _lyude[d]: airlied[d]: Just to make sure: it should always have a single vma?
22:05 _lyude[d]: Mostly trying to wrap my head around how this works, since the fact that we have a list of vmas made me think that it wasn't impossible for a bo to have multiple vmas, which would still mean the list could get modified in-flight when info gets called doesn't it?
22:05 _lyude[d]: or do we only run into more then one vma for internal driver bos?
22:06 _lyude[d]: (i also notice both create and destroy functions seem to grab the ttm lock before actually working with vmas)
22:06 airlied[d]: "it depends"
22:08 airlied[d]: BOs allocated though vulkan will have 0 vma and through GL will have 1 vma per fd they are used on
22:09 airlied[d]: nouveau_cli_uvmm(cli) means userspace controls the vm space which means vulkan driver
22:09 _lyude[d]: gotcha
22:09 _lyude[d]: eesh, back to the drawing board :V.
22:09 airlied[d]: so if you are getting allocations through gbm->zink->nvk they won't have vma
22:10 airlied[d]: I don't think on a modern fedora you should ever see a case where a bo has a vm outside of kernel allocated things
22:14 _lyude[d]: I feel like I'm starting to run out of things to actually look at for this issue. I can't seem to find anything suspicious looking in the gbm paths for nvk, really doesn't seem like there's much that could go wrong in the fb_create paths in the kernel
22:24 airlied[d]: it's most likely going to be the nouveau atomic modesetting paths, but where in that I've no idea
22:25 _lyude[d]: airlied[d]: How would that explain the weird size mismatches between the cursor/primary scanout surfaces on fb creation though? I wouldn't think atomic modesetting would control those
22:29 airlied[d]: oh uf your seeing them on fb create then I've no idea, you should see separate fb creationn for cursor and primary scanout
22:29 _lyude[d]: yeah - that's where things start to get wonky
22:30 airlied[d]: I'd probably start to play with igt and see can you recreate it with something simpler
22:30 _lyude[d]: we will suddenly get a fb creation request that has the tiling parameters of the primary scanout surface which predictably fails
22:30 _lyude[d]: i think i might actually know a test that causes this
22:30 _lyude[d]: which i only just remembered ;-;
22:30 airlied[d]: like nouveau_user_framebuffer_create
22:31 _lyude[d]: yeah - that's where it fails
22:31 airlied: so putting some WARN_ON in nouveau_framebuffer_new gets you consistenly wrong backtraces?
22:32 airlied: it could also be modifiers being wrong then
22:32 airlied: if userspace gives you the cursor bo with the primary modifiers that would be an issue
22:38 _lyude[d]: airlied[d]: so I see a few different errors, which I assume all seem to be related:
22:38 _lyude[d]: *`nouveau_user_framebuffer_create()` fails on `nouveau_framebuffer_new()`, this is where we see it try to create cursor framebuffers with tiling info and primary scanout buffers with the cursor size
22:38 _lyude[d]: * `nouveau_user_framebuffer_create()` fails with -ENOENT, appears to be from `drm_gem_obect_lookup()` failing to find the provided gem object handle
22:38 _lyude[d]: all of the other errors seem to stem from that as far as I can tell
22:39 _lyude[d]: I have to assume the latter issue is caused by the former
22:41 _lyude[d]: also - the first failure ends up returning -ERANGE because of the incorrect tiling info
23:14 airlied: _lyude[d]: how often do you see it? and I assume it's always mutter process
23:16 _lyude[d]: airlied: It seems like it happens in spurts. Like, it'll be fine for quite a while (possibly hours) and then one out of 3 of the displays starts looking as if it's lagging, afterwards that's usually when the blinking happens (where it seems like it's scanning out from one correct fb, followed by some random garbage somewhere in memory)
23:16 _lyude[d]: often times I have to switch to a VT and back to fix it, sometimes multiple times in a row
23:26 _lyude[d]: airlied[d]: also - it is probably worth noting I'm running with `nouveau.atomic=1`
23:28 airlied[d]: It sounds like a userspace bug, does it happen with 2 screens?
23:29 airlied[d]: But narrowing it down to Zink or mutter makes it hard, maybe try running with nvc0 instead of zink
23:32 _lyude[d]: airlied[d]: mhh - i wonder if I can force gnome-shell to use the nouveau gallium driver, but then I assume that just doesn't really work on ampere?
23:32 _lyude[d]: (trying to figure out how to try this without making my desktop laggy haha)
23:33 _lyude[d]: if it is a userspace bug, I have to assume it's still specific to nouveau since I've got two other roommates running fedora on wayland (one with two screens + amd, one with three to four screens + amd)
23:36 mhenning[d]: nvc0 used to be supported on ampere
23:37 _lyude[d]: ah whoops, I meant ada - but, if it worked on that or turing that would probably work
23:37 mhenning[d]: ada and turing also used to be supported
23:37 chikuwad[d]: mhenning[d]: still does work, with minor issues here and there
23:38 mhenning[d]: you can set NOUVEAU_USE_ZINK=false
23:38 mhenning[d]: chikuwad[d]: cool. yeah, I suspected it still worked just haven't tested in a minute
23:38 _lyude[d]: guess I could then make it so that only gnome-shell doesn't use zink. which I assume shouldn't be that big of a deal
23:39 chikuwad[d]: I accidentally was using it a couple weeks ago
23:39 chikuwad[d]: wondered why the banner rendering in steam was broken