01:47AndrewR: does this apitrace (dumped) looks good enough for nv50 (nv92)? https://pastebin.com/326M8SRk
01:58imirkin: AndrewR: not sure what you mean by 'good enough'
02:00AndrewR: imirkin, I mean nothing obviously wrong? For some reason it works for cinelerra developers (on mesa/nouveau, intel, amd/radeon, and nvidia binary) and I have problems..like, hw effects not working for me (this is different branch, not crashing one)
02:02imirkin: not *obviously* wrong, but it's not like i looked closely
02:03imirkin: i have a GK208 and G92 plugged in atm, happy to test it myself
02:03AndrewR: imirkin, do you need binary apitrace file?
02:04imirkin: in order to test it myself, yea
02:06AndrewR: imirkin, https://yadi.sk/d/PkllRZe93J6db9
02:07imirkin: i get the crash you were getting earlier
02:09AndrewR: imirkin, good ....
03:44AndrewR: LIBGL_DRI3_DISABLE=1 fixes effects for me ....
10:59exs: I am glad that here is a chan to nouveau also. I use nouveau and I am very thankful to the work. The best, I get even better performance from nouveau than from the nvidia driver itself that is hard to imagine
11:00exs: I have several questions I would like to ask here. First how to get the temperature of my gpu? My fans seems to run all the time even without any graphic interaction. I just want to control the reason. sensors just show me the temperature of the cpu
11:13mupuf: exs: you can use the "sensors" command
11:14mupuf: and if it makes too much noise, it likely is because I screwed up
11:14mupuf: or you have one of those annoying cards I do not know how to control yet :s
11:15exs: mupuf: https://ptpb.pw/UBZV this is my output
11:16mupuf: odd. Can you show me your kernel logs?
11:16exs: I dont see any information to my gpu
11:16exs: mupuf: bootlog: https://ptpb.pw/DAJS
11:17mupuf: oh dear, you have screwed up your system very badly :D
11:18exs: mupuf: what exactly is bad?
11:18mupuf: First of all, there is no HW acceleration
11:19mupuf: DRM: failed to create kernel channel, -22
11:19mupuf: and second of all, you have the nvidia driver that tries to be loaded too
11:19mupuf: I would suggest you uninstall the nvidia driver
11:20exs: hw: https://ptpb.pw/nR0t
11:20mupuf: then we can check the xorg logs, after you rebooted
11:20mupuf: can I see the full logs?
11:20exs: mupuf: where can i get the full logs? use arch or what you mean with full
11:20mupuf: I meant the "glxinfo" logs
11:21exs: sure: https://ptpb.pw/OL4a
11:25exs: to nvidia. I also see that I have some bin with nvidia-. The strange thing, I have deinstalled everything related to nvidia. I assume that the packages are from the nvidia bin driver (from nvidia.com) that I have installed. I use the same driver bin to deinstall again but it seems that nvidia didnt uninstall the installed packages anymore. If I tray to uninstall it tells me that the driver is uninstalled
11:25exs: already. in the worst case I reinstall my complete system and never touch the official nvidia driver package anymore.
11:32exs: mupuf: I try to clean up the remaining nvidia files
11:32mupuf: exs: Device: llvmpipe (LLVM 4.0, 256 bits) (0xffffffff)
11:32mupuf: that means you are using your CPU for the rendering
11:59leberus__: mupuf: hi! I sent the v6 on monday and as you told me, I put you as a reviewer. Im not sure if there is something else to be done in that regard :)
11:59mupuf: hmm, maybe Ben was waiting for my final ack
11:59mupuf: sorry, will check it out again in a sec
12:00mupuf: leberus__: where are you located?
12:00mupuf: you deserve a cookie :D
12:00leberus__: Now i moved to Nürnberg :)
12:00mupuf: cool city!
12:01mupuf: we had the XDC there in 2012
12:01mupuf: I still use my Suse strap as a key chain
12:01leberus__: Yeah! Before I was in Hamburg, but i like more nürnberg. Maybe because its smaller hehe
12:01leberus__: Were you working at suse?
12:01mupuf: nope, just been there for the XDC
12:02leberus__: Ah okok :)
12:03leberus__: Btw, what does it mean that cookie? Or is just a playword haha
12:03mupuf: well, that basically means you have my gratitude :)
12:03mupuf: and a beer if we meet
12:05leberus__: Of course, that would be a pleasure haha ;)
12:05leberus__: And no gratitude needed, that was fun
12:06leberus__: Now I have to leave otherwise my gf is gonna beat me up. If there is something that needs to be fixed you can tell me here. I"ll read the irc logs later
12:06leberus__: Have a nice day ;)!!
12:07leberus__: And thanks for taking the time
12:27exs: mupuf: so i have removed nvidia files manually in the end.
12:28mupuf: ok, cool! How did it go?
12:28exs: mupuf: it was difficult, manually work. i have downloaded a script that detect which files are managed by packages and which are "free". so i have picked up the nvidia related and removed with root rights.
12:30mupuf: so, can I see your kernel logs?
12:30exs: mupuf: Can we please fix the other bugs? I tried already yesterday the complete day to fix the bugs. Sometimes even my monitor turns black (I assume because of the fact that my rendering happens with cpu)
12:30exs: mupuf: thanks that you ask. sure mom
12:31exs: bootlog: https://ptpb.pw/2O3n glxinfo: https://ptpb.pw/ljkz
12:34mupuf: ok, it is better
12:35exs: the bugs you remained like dms: kernel channel not found etc are fixed now?
12:35mupuf: now, you need a newer kernel
12:35exs: i use arch linux, thats the most recent kernel
12:35mupuf: I think you need 4.12 though :s
12:36exs: damn arch is old like that? :D i was thinking arch is a modern distro with recent kernel and recent packages :D
12:37mupuf: yes! it is
12:37mupuf: but 4.12-rc1 is not even out :s
12:37mupuf: it will be tomorrow
12:37mupuf: so... it will take 2 months for the 4.12to be released
12:38exs: i could use https://aur.archlinux.org/packages/linux-git/ of course
12:38exs: and try out if it works
12:38mupuf: that would work
12:38exs: should i do so or is the 4.10 fine?
12:39mupuf: 4.10 is not fine
12:39mupuf: only 4.12 has pascal support
12:39mupuf: and you'll need a new mesa too :s
12:39exs: aah. so what does it mean for now. that I cant play any game or use my gpu?
12:39mupuf: not until you have a newer mesa and a newer kernel
12:39mupuf: and even then, it will be super super slow
12:40mupuf: your gpu is ... well, quite new
12:40mupuf: and nvidia took forever to give us the firmwares
12:40exs: mupuf: so you are a nouveau developer I guess?
12:40mupuf: I used to be way more active
12:40mupuf: I work for Intel nowadays
12:41exs: wow, I respect the work you and your team do. nouveau is great. for some strange reasons I get with nouveau better performance results than with the nvidia driver I have installed before
12:42exs: I have also bought intel stuff (its quite the best at the moment for single core applications). I am web developer and at the moment single core performance is quite important (e.g. nodejs)
12:43exs: mupuf: does my rendering happen with gpu or cpu now?
12:43NanoSector: nouveau in my experience gives better performance than nvidia proprietary with bumblebee, lol
12:43NanoSector: on optimus at least
12:43karolherbst: NanoSector: in glxgears....
12:44NanoSector: karolherbst: no, in games; bumblebee was often slower than intel gfx for me
12:44karolherbst: then something is broken
12:44NanoSector: i guess
12:44karolherbst: PCIe bandwith bottleneck is a serious issue with bumblebee though
12:44karolherbst: so everything above 60 fps isn't really compareable
12:44karolherbst: at fullhd
12:45karolherbst: you should benchmarks games running at 10fps on intel
12:45NanoSector: i've since moved to windows so dunno the state now
12:46exs: mupuf: and I guess I still have no hardware acceleration? I will come with 4.12?
12:47exs: mupuf: whats about the other errors like "nouveau 0000:01:00.0: DRM: failed to create kernel channel, -22". Should I worry about this?
12:49exs: I also still have "nouveau 0000:01:00.0: DRM: Pointer to flat panel table invalid" is there a way to fix it?
12:52exs: mupuf: are you still there? I also need to ask you something important. My monitor turns off sometimes. Nothing helps except a complete system restart. Can you give me some information if there is a way to fix that?
12:58pmoreau: exs: The "nouveau 0000:01:00.0: DRM: failed to create kernel channel, -22" should be fixed by using Linux 4.12, along with the needed firmwares from linux-firmware
12:58exs: pmoreau: ok thanks. and ""nouveau 0000:01:00.0: DRM: Pointer to flat panel table invalid" ?
13:00pmoreau: The flat panel error message shouldn't be preventing you from using the GPU. It has been showing on for a few generations now. Maybe someyhing that is parsed wrongly?
13:01exs: pmoreau: what do you think about the problem with the monitor? When this happens sometimes I get the message "out of range" from the monitor. Do you think it will be fixed with the new kernel?
13:01pmoreau: And yes, hardware acceleration will come with 4.12: the kernel channel failing to be created is due to missing hw accel IIRC
13:02pmoreau: No clue
13:12jamm: how should i restart GNOME to reload nouveau without rebooting?
13:13jamm: i tried "service gdm3 restart" but after doing that, the screen starts blinking rapidly and stays hung up like that
13:18pmoreau: jamm: Something like that https://phabricator.pmo\reau.org/P22 might have changed a bit though. (this is with no X server running, so you will need to stop that first)
13:19karolherbst: pmoreau: you shouldn't need that sleep though
13:19jamm: got it, thanks a lot! :D this will be a big time saver for me
13:19karolherbst: pmoreau: and you only need to unbind vtcon1
13:19karolherbst: vtcon0 is some virtual thing
13:21pmoreau: Possibly. I think I stole it from mupuf, but I am not sure whether I really used it
13:39jamm: karolherbst: something like this? https://hastebin.com/agamojobol.bash
13:40jamm: removed the sleep and vtcon0 unbind
13:42karolherbst: should do the trick
13:49imirkin: dboyan_: https://anholt.github.io//twivc4/ -- looks like anholt is going to be looking at Sethi-Ullman for vc4 as well.
13:52exs: Question: If I install the nvidia driver for gtx 1080. should I get any benefit or its a complete waste because only kernel 4.12 can support the gpu?
13:52imirkin: nouveau on 4.12 supports it. however the nvidia blob driver should support it across a range of kernels, as it's an add-in driver.
13:53exs: but the funny point is that the nvidia driver give me more bad results than with nouveau on 4.10
13:53imirkin: nouveau was just doing modesetting, no acceleration, on 4.10
13:54imirkin: in either case, this is not a support channel for the nvidia driver
13:54imirkin: if you have an issue with their drivers, you can post a message in their forums.
13:56exs: I dont have any issue with their drivers. I just try to understand why nouveau is still better even its not supported for 4.10
13:58imirkin: it's supported - just not for acceleration
14:01jamm: pmoreau: script didn't work :/
14:01jamm: it brought me to the same environment
14:01jamm: i mean, it doesn't seem to show the changes i made to exa shaders unless i reboot
14:02jamm: looks like there's some other way which can be done.. will look into it
14:04pmoreau: Maybe it is not reloading the nouveau module you expect it to?
14:17exs: pmoreau: i restart the test.
14:27hakzsam: pmoreau: patch pushed btw
14:27pmoreau: hakzsam: Ty :-)
14:27exs: pmoreau: re....sry maybe I interprete the results wrong but I get following: for nouveau: https://ptpb.pw/kCIK for nvidia: https://ptpb.pw/d2Tf does it seem that nvidia is slower in the performance?
14:28imirkin: exs: no
14:28pmoreau: exs: Look at the first 2 lines of the second paste
14:28imirkin: exs: perhaps you should read the messages fully
14:29pmoreau: Also, glxgears is not a perf benchmark :-)
14:35exs: hm right.
14:37jamm: pmoreau: got it to work, i had to use "modprobe nouveau" instead of "rmmod nouveau.ko". Makes sense coz I don't have such a file anyways
14:38jamm: for others who are wondering just in case: i use debian stretch with GNOME
14:38exs: i want to test to disable nouveau. but in arch its always loaded. can someone tell me a safe way to unload nouveau? at the moment my only idea is to set nomdoeset in the kernel parameters
14:39pmoreau: Ok. I guess insmod was used because the script was used in the same dir where the module was built
14:39jamm: exs: you first need to stop X server, whichever one you're using right now
14:39jamm: i use GNOME, so one of the ways X can be stopped is "killall -3 gnome-shell" followed by "service gdm3 stop" in a separate terminal session
14:40pmoreau: modprobe.blacklist=nouveau is better than nomodoset I would say, or nouveau.modeset=0
14:40exs: jamm: I would even reboot but how to prevent nouveau to be loaded?
14:40jamm: ah, my bad, it's the other way around.. "service gdm3 stop" and then the killall...
14:40jamm: pmoreau: i see, makes sense
14:41exs: pmoreau: whats about /etc/modprobe.d/blacklist < "blacklist nouveau"?
14:41jamm: exs: ah, if you don't want nouveau to be loaded at all, i believe you need to blacklist nouveau and configure your X config to use some other driver
14:42imirkin: it all greatly depends on how things are set up
14:42pmoreau: Works as well. Same effect as having modprobe.blacklist=nouveau
14:42imirkin: if you're having trouble operating your distro, ask in a distro-specific support chan
14:51jamm: hakzsam: in https://cgit.freedesktop.org/~hakzsam/mesa/commit/?h=gm107_scheduler&id=a153e2e1317957f82da240a21557004c9ce0d2dc, you're running out of barrier slots, so you reuse 0x5 for write bars. Am I correct in this speculation?
14:57hakzsam: jamm: that's correct
18:58syn__: I will just put the question here: I have a MacBook Pro with an external monitor, a Samsung Ultra-Wide 3440x1440, everything is working fine except when the mouse cursor goes to 'x-axis=0' in the external monitor. Once it's there, the external monitor just goes gray and keeps this way. The X11 server is still working and everything is still fine, but there is no way to recover the screen. It is really weird an dI don't know what to do
18:58syn__: It is working fine with lower resolutions like: 25XX x 1080
18:59syn__: is there any suggestion ? Or any workaround? I made a python software to avoid the mouse cursor to go to avoid those coordinates, but it is too CPU consuming.
18:59syn__: Thank you very much
19:00karolherbst: sounds like something I heard before?
19:00karolherbst: imirkin: any ideas?
19:00imirkin: yeah, sounds familiar
19:00imirkin: i don't remember what, if any, resolution there was
19:00karolherbst: I think it was also 4k
19:02syn__: lol, really? How did you solve it ? I was thinking about debugging or something to understand what happens
19:02syn__: there is no crash anywhere, no error in dmesg, no error in Xorg
19:02syn__: the screen just goes unusable
19:03imirkin: well, step 1 is to update the kernel
19:03syn__: I use archlinux, is everything up-to-date, a lot
19:06imirkin: and which kernel is "up to date"?
19:07syn__: xd 4.10.13-1
19:08imirkin: hmmmm.... trying to remember if there's anything in 4.11 or headed for 4.12...
19:10syn__: I will start looking about how to debug the driver in the meanwhile, it's a pity to have such screen and don't be able to use it in full resolution :(
19:14syn__: I will start with this
19:15syn__: make sense? sorry , my first time xD
19:24syn__: shit, valgrind: failed to start tool 'mnt' for platform 'amd64-linux': No such file or directory
19:24imirkin: unfortunately tracing that stuff is especially difficult
19:24imirkin: it's commands sent to the EVO channel from within the kernel
19:24imirkin: so valgrind-mmt won't help
19:25imirkin: you can boot with a lot more debugging enabled
19:25imirkin: and see if there are suspicious things going on when it happens
19:27syn__: and do you know if any combination of other tools like xinerama or stuff like that can help?
19:33karolherbst: maybe it is simply a buffer overflow or so
19:33karolherbst: maybe running X under valgrind shows something? But I fear that X itself has soo many issues, that you won't find the one you need
19:35imirkin: X itself isn't the cause here
19:35imirkin: it doesn't control any of this stuff
19:35imirkin: the kernel driver does
19:38imirkin: could be that X-1 is supposed to be written somewhere, but 0-1 explodes it and it overwrites fields it's not supposed to
19:39imirkin: just a random guess
19:40syn__: should I see something in dmesg when it happens ?
19:42syn__: I do not understand why I cannot see any error message anywhere
19:42syn__: it's frustrating xD
19:51syn__: by analyzing what happens, it's seems a memory corruption issue, but not corrupted enough to crash the driver
19:57karolherbst: there are in kernel things for stuff like this though
20:00syn__: karolherbst: for example? sorry, first time with this issues, it would be nice to have some help for tools if it's possible :)
20:00syn__: I would really apreciate that
20:01imirkin: so first off, you can boot with nouveau.debug=trace which will print a TON of stuff
20:01imirkin: and then you can boot with drm.debug=0x1e which will print a HUGE ton of stuff
20:03syn__: I like it, thx ;)
20:03john_cephalopoda: I just had a freeze, could recover from it and dmesg looks like it's a nouveau thing.
20:05john_cephalopoda: It happens nearly every time when I run chromium.
20:07john_cephalopoda: Mesa 17.0.5, Kernel 4.11, Nouveau xorg driver 1.0.15
20:10pmoreau: imirkin, curro: If I have https://hastebin.com/fobibosedu.m, so both kernels inside the same CL program (and therefore SPIR-V module), I end up with both in the same nv50/nvc0 program.
20:11imirkin: pmoreau: correct
20:11imirkin: you're supposed to keep a mapping of name -> start offset
20:12pmoreau: So when Nouveau launches any of them, it will report a share mem usage of (16 + 4) * 4 bytes, rather than 16 * 4 in one case, and 4 * 4 in the other. Same for reg usage
20:12pmoreau: imirkin: That mapping is already through the syms attribute for compute programs
20:12pmoreau: *already done
20:12karolherbst: syn__: no clue, would have to dig through the linux config thing myself
20:13pmoreau: So my problem is how to overreport local mem and reg usage for each kernel.
20:14john_cephalopoda: Any clues what could cause the freezes I experienced and how to get around them?
20:14john_cephalopoda: Oh, forgot to say: 01:00.0 VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 645 OEM] (rev a1)
20:14imirkin: pmoreau: yeah, it'd on a per-compiled-object basis
20:14imirkin: pmoreau: imo it's ok to do it that way. dunno. maybe not. haven't really thoguht about it that much.
20:14pmoreau: imirkin, curro: I thought of ignoring other kernels when translating the program, but at compile time I don't know which one will be launched,
20:15pmoreau: imirkin, curro: So, also have a mapping name -> (reg, local mem) usage?
20:16imirkin: pmoreau: well, at that point you should just return separate blobs for each one
20:16curro: pmoreau: why don't you use pipe_compute_state::req_local_mem? that should be per-kernel IIRC
20:16syn__: thx everyone, I will try some approaches ;)
20:17pmoreau: curro: This does not take into account local mem declared within the kernel, only dynamically allocated one I think.
20:18pmoreau: imirkin: Within the same Nouveau program? Or have it split even before that?
20:18pmoreau: john_cephalopoda: You might have more luck using the blob gr firmware instead of Nouveau's one.
20:19curro: pmoreau: ah, yeah, that's right, but it shouldn't be too hard for the back-end compiler to figure out how much static local memory each kernel uses
20:20pmoreau: curro: Sure! However, that will only work for local mem usage, but not for regs.
20:20curro: pmoreau: regs?
20:21pmoreau: john_cephalopoda: IIRC there are quite a few issues with timeouts in ctxswitch for GK106/GK107 on the bugzilla
20:21pmoreau: curro: registers. A kernel will fail to launch if you use more regs per workgroup than a given limit
20:23john_cephalopoda: pmoreau: Ah, well. It only happens when running chromium (which I don't use often), so I'll just keep using it and wait for a fix ;)
20:24curro: pmoreau: uhm... but *that* is even more hardware-dependent, i don't see how you could take that into account anywhere else other than in the compiler back-end
20:24pmoreau: john_cephalopoda: Those bug reports are a few years old already, so… you might wait a bit more
20:25john_cephalopoda: pmoreau: Well, it's not bad enough to drive me into the arms of the proprietary blob again ;)
20:26pmoreau: curro: Right, however if I split the SPIR-V so that each kernel has its own section, it won't be a problem. So, should I do that, or handle that in Nouveau instead?
20:26pmoreau: john_cephalopoda: :-)
20:27pmoreau: curro: own section, as in clover::module.sections
20:28curro: pmoreau: why would splitting kernels into sections change the situation?
20:29pmoreau: curro: I was going to say: "Cause when the compute state is created, it is done around a single section, not all sectioms of a program?"
20:29pmoreau: curro: But then I remember that clover sends in the first exe it founds…
20:29pmoreau: So that won't work :-D
20:31curro: pmoreau: but also that wouldn't remove the need for some infrastructure in the compiler backend for computing the amount of local memory effectively needed
20:33pmoreau: curro: Sure, but I was already parsing the static amount required by each kernel, and adding that to the dynamic amount requested, but the problem was the amount being summed between diff kernels.
20:34pmoreau: curro: Souns like I'l go with Nouveau keeping track of it then. In which case, I'll keep track of the static local mem usage in Nouveau as well.
20:34curro: pmoreau: another posibility would be to move the 'pc' kernel identifier from pipe_grid_info into pipe_compute_state, effectively making pipe_compute_state per-kernel, but still you'd need some collaboration from the compiler back-end so it doesn't really solve the problem
20:36pmoreau: I’ll have the stuff in Nouveau. That also has the advantage of not needing to touch the radeon stuff. :-)
20:37curro: pmoreau: heh, right
20:38pmoreau: It might disappear I guess, if support for older cards is added to ROCm?
20:45airlied: rocm is pretty limited
20:46pmoreau: airlied: In terms of supported architectures, or even OpenCL support? (I haven't checked the latter.)
21:22phinxy: Is it possible with Nouveau to work with Blender on a gtx 760?
21:27imirkin: should be
21:27imirkin: can't say it's been tested much
21:27airlied: pmoreau: supported cpu/gpu combos
21:30pmoreau: airlied: I don't know whether AMD is planning to add support for older GPUs, or whether the community is going to do that.
21:30pmoreau: I didn't meant that Radeon support in clover would disappear overnight, but maybe when rocm supports more cards.
21:39karolherbst: pmoreau: pro tip: declare as unmainteind "for years" and remove it :p