00:08RSpliet: pmoreau: The first reply on Gustavo's cover-all patch was Alex Deucher saying "Can you please split this up per driver? A comment below as well."
00:09RSpliet: I don't think ce9dcf100... should be dropped after all ;-)
02:24airlied: imirkin: not sure how much you care https://pastebin.com/raw/NStKJf0g
03:22imirkin: airlied: heh. which compiler, out of curiousity?
03:22imirkin: i'm not sure there's a macro-safe way of avoiding that...
03:33HdkR: GCC 8.x has that warning
03:36airlied: imirkin: gcc 8.2.1
04:40imirkin: karolherbst: if it's not too difficult, i'd appreciate a mmt of https://hastebin.com/wajutejeja.cs with nvidia blob on kepler1 or kepler2
04:41imirkin: it appears this is a fairly minimal setup that triggers the hang for me
04:41imirkin: it definitely has something to do with the specific geometry of the execution -- different number of points or invocations will not necessarily cause a failure
04:42imirkin: i tried flipping it from predication to branches, but that didn't help (not that i necessarily thought it would...)
16:58ReinUsesLisp_: what compute engine does Maxwell go through? I'm getting writes as if it were gk104 but in nvc0_compute.c I see gf100 registers being written
18:47sgt-hartman: Hi, with an nvidia card and nouveau drivers, i am not able to use a custom EDID firmware for my old 15khz monitor (using drm.edid_firmware=edid/edid.bin). The connector of this monitor is not enabled if i don't force with video=VGA-2:e kernel boot param. With the same setup, but replacing the video card with a radeon one, the edid is read correctly and i don't have to force enabling output.
18:48sgt-hartman: (i'm on Fedora 29 , kernel 4.20.8, stock distro packages)
19:08imirkin_: sgt-hartman: what's the physical way in which this monitor is connected?
19:09imirkin_: is it just a VGA cable direct, or is there something funnier?
19:09sgt-hartman: Hi imirkin, it is connected via a VGA to scart adapter
19:09imirkin_: heh. SCART. that's a LONG time ago
19:10sgt-hartman: it is an UMSA scart adapter: http://arcadeforge.net/UMSA/UMSA-Ultimate-SCART-Adapter::57.html?language=en
19:11imirkin_: vga has HPD, right? i wonder if it's hooked up...
19:11sgt-hartman: hmm, what is HPD ?
19:11imirkin_: for s-video/composite, we had "load detection"
19:11imirkin_: hot-plug detect
19:12sgt-hartman: In fact, with my radeon card the connector is enabled, not with nouveau
19:12imirkin_: yeah, but there could be other differences
19:12sgt-hartman: without forcing it with video=VGA-2:e
19:12imirkin_: didn't you say this used to work with nouveau though?
19:13sgt-hartman: yes, it works with this config:
19:13sgt-hartman: video=VGA-2:e and a modeline forced in Xorg
19:13sgt-hartman: but i have vsync issues, which is my initial issue
19:14imirkin_: right, and if it doesn't think it's connected, you probably won't get vblank events reported either
19:14sgt-hartman: possible right.
19:15imirkin_: didn't you say vsync worked on earlier kernesl though?
19:15sgt-hartman: with the radeon i have vsync with xorg
19:15sgt-hartman: yes your right
19:15sgt-hartman: this config worked well maybe one or two years ago
19:16imirkin_: if you could try older kernels, e.g. do a bisect, that would help
19:16sgt-hartman: i even made a long doc about this config in github by the time https://github.com/TiBeN/15khz-arcade-pkg/blob/master/doc/15khz-package-documentation.md
19:17sgt-hartman: But by the time i never used a custom EDID
19:17sgt-hartman: just force enabling 'video=VGA:e' and custom modelines in xorg. It worked well with vsync
19:18sgt-hartman: for KMS i used a patched kernel, but it was not required for xorg
19:18sgt-hartman: to work correctly
19:19sgt-hartman: but, right, trying older kernel is a good idea
19:26imirkin_: sgt-hartman: was SCART used outside of France?
19:28sgt-hartman: hmm, in Uk i think
19:28sgt-hartman: maybe other countries in Europe
19:30imirkin_: yeah, apparently popular in a lot of Europe.
19:31sgt-hartman: was very common in 80s/90s
19:32imirkin_: (i spent some time in France in the early 90's, so definitely familiar with it, but never saw anywhere else)
19:33HdkR: Basically it was only ever in the EU. Used in a bunch of random places over there :D
19:35sgt-hartman: it was the most common standard for videocassette recorder, video game consoles etc.
19:36sgt-hartman: and was a pain to plug behind the tv :)
19:36sgt-hartman: because of its shape
19:36imirkin_: didn't come out easily though =]
19:37imirkin_: so you doubled the pain if you had 2 game systems
19:37imirkin_: and wanted to switch between them :)
19:39sgt-hartman: yeah, or you had to use multi scart adapter, but it took a lot of place
19:39imirkin_: not to mention cash
19:45sgt-hartman: i just tried an older 4.12 kernel which does not solve the vsync issue. I suspect a regression in the xorg part of the nouveau driver. I check if i can downgrade in fedora
19:56imirkin_: i did recently put out a new release of xf86-video-nouveau, but it shouldn't have materially affected that
19:56imirkin_: although if in the new fedora you're using modesetting+glamor instead of xf86-video-nouveau, the vsync logic there is a bit different
19:58sgt-hartman: hmm, i'm pretty sure glamor is disabled by default (but i'm not an expert though)
19:59imirkin_: for xf86-video-modesetting? it's definitely enabled by default.
19:59imirkin_: for nouveau, it's off by default
19:59imirkin_: however some people prefer to avoid having xf86-video-nouveau entirely, instead relying on the GL stack for all acceleration
19:59imirkin_: and those people appear to have convinced fedora that this is a good idea
20:00imirkin_: i disagree fairly strongly, but ... i also have a long history of not being listened to
20:00sgt-hartman: Oh, ok. Here are the limits of my knowledges of the graphic stack
20:00imirkin_: (or perhaps that's too strong ... people listen, they just disagree)
20:05sgt-hartman: does it has something to do with exa ? theses are two acceleration methods right ?
20:05imirkin_: don't worry too much about it
20:06imirkin_: just think of it as 2 separate DDX's
20:06imirkin_: (which is what it is)
20:06imirkin_: one is xf86-video-nouveau and one is xf86-video-modesetting
20:06imirkin_: both have independent and different magic ways of providing acceleration
20:06sgt-hartman: okay :)
20:07sgt-hartman: in my system, the package "xorg-x11-drv-nouveau" is installed
20:08imirkin_: installed != used
20:08imirkin_: if your logs have NOUVEAU it's used
20:08imirkin_: if they have "modeset(0)" then it's not used
20:08sgt-hartman: yeah i have
20:08sgt-hartman: i check
20:10sgt-hartman: there is "NOUVEAU(0)" everywhere in xorg.log
20:11imirkin_: either you're using an older version of fedora, or they made the cut-off somewhere else
20:11sgt-hartman: and "DRI2". according to man nouveau, i use "exa"
20:11imirkin_: yeah, don't worry about that =]
20:11sgt-hartman: yeah okay haha
20:12imirkin_: that's the "magic" i was talking about
20:12sgt-hartman: i understand right
20:18pmoreau: RSpliet: I think he had more Nouveau-related fixes in that big patch, but I’d need to have another look to be sure.
20:42sgt-hartman: seems really complicated if not impossible to downgrade xorg nouveau drivers without downgrade all the xorg related dependencies. i'll check for another harddrive and try previous distros versions
20:43imirkin_: yay binary distros!
20:43sgt-hartman: dependency hell
20:44sgt-hartman: theses distros are great when they work out of the box, but screwing is complicated
20:47sgt-hartman: what's your ? gentoo ?
20:47imirkin_: hardly perfect
20:48imirkin_: but thus far the most palatable of all the other options i've encountered
20:49sgt-hartman: okay. For a system developer i suppose its the best
21:22pmoreau: imirkin_: What is the `join` attribute of `Value` for? I guess it’s not the join for control flow, so is it for variables in a phi instruction to refer to its result (i.e., `a = phi(a', a'')`, both a' and a'' have` join == a`)?
21:58imirkin_: pmoreau: to join multiple LValue's
21:59imirkin_: basically all the defs get thrown onto a single LValue
21:59imirkin_: and then those LValue's ->join gets set to the LValue which received their defs
21:59imirkin_: this is also used to figure out which RIG node to use for a particular LValue
22:01pmoreau: imirkin_: So, that would occur when coalescing multiple variables into a same register, right?
22:01pmoreau: I see
22:05no_like: Hi, guys, possible u able to advice smth with my issue (freezing WM with neoveau, but works without acceleration), full issue discriptoin: https://bbs.archlinux.org/viewtopic.php?id=244338
22:19no_like: sad =x
22:44RSpliet: no_like: first of all thanks for reporting that bug. I'm afraid your full combination of tools is quite unusual, but on the plus side it appears that you are using a nice and fresh kernel and mesa.
22:45RSpliet: Although the obvious downside of that is... I can't advise you to first try newer software and keep my fingers crossed your problem had already been solved
22:48no_like: just FYI, i create bugreport on https://bugs.freedesktop.org/show_bug.cgi?id=109681
22:48RSpliet: no_like: Is there any chance you could see if your problem is specific to swayWM. Do you have any other wayland-compatible WM installed by any chance? 'd Be nice to narrow down the problems a bit
22:49RSpliet: Yep, saw the e-mail
22:49no_like: i able to try tommorow gnome/ or waston
22:50no_like: but just suppose,that acelleration don't relate to WM
22:50RSpliet: Also, I recommend you to attach your (full) dmesg to the bug report rather than linking to an external website. Helps with archiving
22:51RSpliet: If WM makes no difference... hmm... is this some brand new wayland enabled firefox, or is it still a xwayland-contained firefox?
22:52RSpliet: The GT710 card *should* work. I know that very infrequent hangs can occur on any GPU, but I don't think there's anything special to that card. I have similar cards running Firefox and other software in Gnome Shell (which critics would regard as the ultimate fuzzing tool) on Wayland
22:53no_like: actually i run firefox-nigthly (and it still xwayland)
22:53no_like: although try chromium
22:54no_like: firefox-nightly and firefox freez system from the lounch
22:54no_like: chromium work before the first button/action
22:55RSpliet: Yeah, FF isn't supposed to crash that quickly obviously ;-) I've never seen it do that except when I stubbornly force-enabled all sorts of GPU rendering. That was in pre-we-can-kill-the-app-and-save-Xorg/wayland days.
22:57no_like: and more interesting with adding nouveau.noaccel=1 it's work
22:57no_like: crappy, with side effects, but works
22:57RSpliet: Sadly I know too little about what might be going wrong. I can make uneducated guesses, but I'd rather leave that sort of post-fact decision making up to a certain president
22:57RSpliet: Well, that's not interesting at all
22:58no_like: at least i will be glad to help you with assistence
22:58RSpliet: That's basically telling nouveau to pretend your GPU is a (rather expensive) device to ship pixels from DRAM to your monitor
23:01RSpliet: I'm afraid my advice as this point is patience. With a bit of luck, some people over at Red Hat might be interested in wayland-related bugs and find a gap in their schedules.
23:01RSpliet: Sadly, there is not a quick fix that'll get you sorted quickly
23:04no_like: Thenk you for your support, i will be keep in touch if u will need more info about this bug. Good luck
23:05imirkin_: i definitely heard someone complain about firefox and wayland