09:31 RSpliet: karolherbst: oh... yes, I guess post-RA the bars have been emitted. insn_sched has the advantage of working on a BB level. DIdn't look into that much tbh, could be that there's an opportunity for increasing distance between tex ops and texbars...
09:45 anEpiov: mm... weird glitches with 4.13, squared glitches in windows that remain when windows dragged
09:45 anEpiov: they only go away when moving the window off the screen.
09:46 anEpiov: squared splotches
09:46 anEpiov: so far appeared in different programs.
09:46 anEpiov: they appear over time.
09:49 RSpliet: anEpiov: could you share a bit more details on that? GPU model? Version of Mesa? Perhaps a screenshot as well?
09:50 RSpliet: I don't think I've seen something like that before, but I'm using Gnome Shell/Wayland and only cards newer than G80...
09:50 anEpiov: RSpliet: all latest, I when into dmesg and Xorg.0.log to see something but nothing there.
09:51 anEpiov: RSpliet: wasn't happening with 4.9
09:51 RSpliet: I have once seen that on a GeForce FX (using the official driver, mind you), but in the particular case the card was simply overheating because the fan broke
09:51 RSpliet: anEpiov: could you paste an (unfiltered) copy of dmesg and glxinfo | grep render onto a pastebin-like website and share the URL please?
09:51 RSpliet: whoops
09:51 anEpiov: RSpliet: lm_sensers report nouveau temps?
09:51 RSpliet: just glxinfo, no need to grep
09:51 RSpliet: should do yes
09:52 anEpiov: RSpliet: right now I can't because I am on another machine. But what I will do is share a pic of the glitch.
09:52 RSpliet: which GPU is it?
09:53 anEpiov: 570 I think
09:56 RSpliet: Ah ok so something something Fermi somethingmore and probably GF108. That's unexpected... I take it you jumped from kernel 4.9 to 4.13. Do you have the old kernel laying around to verify it's still functioning correctly?
09:57 anEpiov: yes I did
09:57 anEpiov: from 4.9 straight to 4.13
09:57 anEpiov: is that wrong??
09:57 RSpliet: No, that's not wrong
09:58 anEpiov: old kernel deleted for good
09:58 RSpliet: Ah now that's a shame. It'd be nice to localise the change that caused this erroneous behaviour, and since a lot changed between 4.9 and 4.13, there's a lot of guesswork.
09:59 anEpiov: and there's whan picky game crashing always at the same spot the bastard!!!
10:00 anEpiov: when I hide behind a place and knock with the hand I get instant crash
10:03 RSpliet: one problem at a time ;-) If you're confident with building kernels you could help out on finding the culprit for your desktop corruption issues by performing a bisect on the kernel tree. Think there's ~300 patches on nouveau between 4.9 and 4.13, so with 9 kernel compilations you should be able to find the exact patch that broke your set-up. Although you might save some time grabbing a pre-compiled 4.11 and either 4.10 or 4.12 fr
10:05 RSpliet: But do verify whether it really is a kernel issue, to me it sounds more like a bug that creeped into the DDX (if it's a 2D desktop env) or Mesa (in the odd case you use Glamor instead of the DDX or a 3D accelerated desktop like Gnome Shell)
10:06 RSpliet: I have to leave unfortunately, but if you have the time to make that debugging commitment it'd be very helpful. Make sure to verify the entire stack works prior to that though, would be a shame to build 6 kernels and then find out it was a problem in llvmpipe (and not actually using nouveau 3D accel) or a dangling binary driver module getting in the way of Mesa.
10:18 anEpiov: I don't use any fancy DE's plain WM
10:18 anEpiov: interesting so it has to do with the 2D part.
10:18 anEpiov: RSpliet: actually, I am using an early 4.13 release, i'll try the latest one.
13:42 imirkin: anEpiov: are you, by any chance, using the 'modesetting' ddx? if so, please switch to xf86-video-nouveau.
13:43 anEpiov: I think I do, how to tell?
13:44 anEpiov: I recall seeing something about DDX in Xorg.0.log
13:44 anEpiov: how to disbale modesetting?
13:47 imirkin: anEpiov: i think some distros go to some length to castrate xf86-video-nouveau... so you'd have to undo that. xf86-video-nouveau should be getting used by default if it's installed though.
13:48 anEpiov: it's installed
13:48 imirkin: pastebin your xorg log
13:48 anEpiov: I am on a different pc
13:48 imirkin: or just see if it says modeset(0) or NOUVEAU(0)
13:48 imirkin: if it says NOUVEAU(0): bla bla bla, then you're using nouveau
13:48 imirkin: if modeset(0), then modesetting.
13:49 anEpiov: aright lemme check
14:02 Tim_: Hello, anybody got experience with Intel + External GPU working together
14:03 Tim_: I want to use the on board intel gpu for the screen, while i use the NVIDIA GPU for calculation. While nomodeset allowed me to initially start a xorg session, the installation of the nvidia driver has blocked this out
14:04 Tim_: currently I've got a setup with a working NVIDIA gpu (for calculation) and no screen session (but a terminal session)
14:04 Tim_: i now only need the screen to work as well. Any suggestionsM
14:04 Tim_: ?*
14:17 anEpiov: Tim_: the application should have the option to detect and allow choosing gpu
14:18 Tim_: yes, that it does
14:18 Tim_: this is apart from an application though
14:18 imirkin_: Tim_: you'll want to ask karolherbst -- he has a pretty good system for all that.
14:18 Tim_: unless you count nouveau (lightdm) as an application
14:19 Tim_: got contact information for karolherbst
14:19 Tim_: ?*
14:19 imirkin_: Tim_: although ... maybe not if you want to use as an external screen
14:19 imirkin_: he mainly just flips between nouveau and nvidia blob [for tracing]
14:19 karolherbst: currently no time, will respond in like 1 hour or so and yes, all my screens are connected to the intel GPU
14:19 Tim_: at the moment i just want my intel gpu to show a browser (for instance)
14:19 karolherbst: so nouveau doesn't drive any screen anyway
14:20 karolherbst: all by intel
14:20 imirkin_: Tim_: if you're looking to do it all with blob, you're in the wrong place
14:20 Tim_: o ok
14:20 imirkin_: with nouveau, the second screen should be pretty seamless - you just have to make sure there's a DDX attached to it, and then use reverse prime.
14:21 imirkin_: afaik the whole "second gpu" thing is a pretty sore spot for nvidia blob drivers, but i'm no expert on those.
14:21 anEpiov: karolherbst: 'all my screens'... how many screens do you need?
14:21 imirkin_: nor is anyone here.
14:21 Tim_: @karolherbst then do you use nvidia for calculationsM
14:21 Tim_: @karolherbst then do you use nvidia for calculationsM?*
14:21 karolherbst: anEpiov: well, I have 3 ports and all are connected to the intel GPU
14:21 karolherbst: Tim_: well, I have bumblebee installed
14:21 karolherbst: and adjusted my system so that I can switch the GPU driver within seconds
14:22 Tim_: any reference to how i can acquire that setup as well?
14:22 karolherbst: use bumblebee and use the dummy X driver for the nvidia GPU
14:22 imirkin_: it's predicated on not using any outputs attached to the nvidia gpu though.
14:22 karolherbst: but then you can't display anything on ports connected to the nvidia GPU
14:23 Tim_: that would not be the case, the gpu is only for deep learning stuff
14:23 Tim_: but i would be able to preform calculations with the dummy X driver?
14:23 karolherbst: Tim_: well yeah, then you can do things like "optirun -b none bash" and execute stuff like "DISPLAY=:8 ./your_deep_learning_application"
14:24 karolherbst: bumblebee starts a second X server on the nvidia GPU without any heads
14:24 Tim_: ok, so now installing bumblebee
14:25 karolherbst: bumblebee also has this bbswitch module to turn the nvidia GPU on/off automatically
14:25 Tim_: for display, not for use with cuda, right?
14:25 karolherbst: but we don't support bumblebee with nouveau (allthough I sometimes use this for piglit/CTS)
14:25 karolherbst: Tim_: well, it turns the nvidia GPU off if not in use
14:26 karolherbst: everything cuda related should pick up the GPU anyhow as long as nvidia is loaded I think
14:26 karolherbst: there isn't even a X server needed afaik
14:26 karolherbst: not quite sure, never played around with cuda until now
14:26 Tim_: true, though while i had a working setup without the nvidia gpu (and drivers) the install of them messed up my intel setup
14:27 karolherbst: right
14:27 karolherbst: usually the bumblebee installation doesn't mess up intel, but installs nvidia drivers
14:27 karolherbst: alone for this it's worth installing
14:27 Tim_: bumblebee could provide with a solution that it tells my lightdm to only look for drivers concerning intel, right?
14:27 karolherbst: kind of, yes
14:27 karolherbst: well
14:28 karolherbst: in the perfect world nvidia is installed in a way, that the main X server doesn't know there is nvidia stuff installed, hence ignoring it
14:28 karolherbst: and normally this is exactly done by bumblebee
14:28 Tim_: does this mean a purge of my current nvidia drivers?
14:28 Tim_: manually or automatically?
14:29 karolherbst: then there is this optirun command, which offloads OpenGL workload on the nvidia GPU, but copies buffers to display it on the intel X server
14:29 karolherbst: but "optirun -b none bash" can be used to start the second X server in the background without setting up offloading
14:29 karolherbst: Tim_: no idea, I doubt it will repair a broken setup
14:29 karolherbst: maybe it does
14:29 karolherbst: dunno
14:30 Tim_: Ok, what order should i follow, first ubuntu then bumblebee, then ... M
14:30 karolherbst: this is super distribution specific, so you might ask people who might know
14:30 Tim_: Ok, what order should i follow, first ubuntu then bumblebee, then ... ?*
14:30 karolherbst: Tim_: yeah, first ubuntu, then install bumebleee
14:30 karolherbst: everything should be setup then
14:30 karolherbst: you can install the mesa demos then (like glxinfo and stuff)
14:30 Tim_: ok, sounds like a plan. Thanks for the advice !
14:30 karolherbst: glxinfo should print intel as the vendor
14:31 karolherbst: optirun glxinfo should print nvidia
14:31 karolherbst: there is also the #bumblebee channel for proper support
14:31 Tim_: o ok. I didn't know bumblebee provided this solution
14:32 Tim_: thanks karolherbst!
14:32 karolherbst: well, it's a hack and has a bigger overhead then DRI_PRIME offloading
14:32 karolherbst: *than
14:41 albamart: i am posting the last data to the channel, we talked about how alus remain allocated, normal formation is that Compute Units have their per wave allocated resources, mioaw does it by in parallel inrementing the the registers per Compute unit, one reg is unique but can trigger bank conflict for the later instruction, if that alu is reused
14:41 albamart: http://frederikaalund.com/wp-content/uploads/2015/09/Real-time-Rendering-Using-Layered-Depth-Maps.pdf
14:42 albamart: similarly memory operations can be reused, allthough writing to the same texture as reading is undefined, it will succeed as discussed there
14:42 albamart: if done not not correct, as the natural stream would be normally, then of course the shader is messed up
14:52 albamart: the spec is correct, overwriting shared/local memory or global memory that way would trigger undefined behavior, it'll succeed but render incorrectly in most cases naturally, but overwriting register absolute addresses would not perform writeback to persistent pool, hence i think at least then the behavior is never undefined
14:53 albamart: the point is that this way one can bypass fetch and decode, and go well below 1ns resolution
14:53 albamart: in the graphics shader, similarly to opencl counters
14:55 albamart: so the real code is assembled with many tricks that would need to work together, but generally is very thin and easy for any sort of purpose, be that feature emulation or scheduling
15:04 albamart: in other words single-pass prefix scan is still possible with very fast methods, be that with specially designed memory rewrites or registers does not matter
15:07 albamart: it is very effective..but slightly complex for the most, someone named mark harris had described it allready in a publication in 2016, where only requirement is that fragmend shader could write i.e scatter to memory
15:09 albamart: doing that in hw circuit fixed, is somewhat even less flexible and imo even incorrect, but it hides the most complexity for every day grapgics programming
15:09 albamart: error, the year was 2006 i meant
15:11 albamart: also miaow is readable code , the hw implementation of gcn cards, but hats off, it can be very complex and timeconsuming to write and read both
15:11 albamart: at least under pressure
15:13 albamart: hence bigger companies really require 10years of experience + education, to deal with such things
15:14 albamart: from another angle, i disagree, that those requirements would need to be there for sw driver programming nowdays when most heavy work has been done
15:19 albamart: the thing is compiler internals have been mainstream for quite a while now, but hw code publications is a new thing, if people are able to freely fetch hw designs from network nowdays, it could be possible that the requirements on such tasks get somewhat relaxed later too as a result
15:22 albamart: anyways good luck to you then, and i head off , dealing with different things including programming and personal life issues! bye.
15:42 mzki: hi, I'm reading the following comment on Dual-link DVI support at https://nouveau.freedesktop.org/wiki/FeatureMatrix/
15:42 mzki: "Works, if the VBIOS gives enough memory bandwidth by default"
15:42 imirkin_: i don't think that's a practically relevant comment
15:42 mzki: I think this might be related to a more general question I have
15:43 mzki: that is, does an option rom found on the card (GTX 660 Ti) need to be run at boot for the card to be usable?
15:44 imirkin_: depends what you mean by 'run'
15:44 imirkin_: something somewhere needs to initialize the card
15:44 imirkin_: that can either be the option rom
15:44 imirkin_: or it can be a driver which parses the init tables in the vbios and does the same thing the option rom would.
15:45 imirkin_: the init tables provide a language which i *think* is turing complete, although i haven't looked at it formally
15:46 imirkin_: but when e.g. nouveau does it, it's all within a sandbox of sorts which only lets it mess with the gpu.
15:46 mzki: ok, thanks, i'm thinking about a coreboot based setup that doesn't load option roms
15:47 imirkin_: i think that ought to work, but i guess i'm not 100% sure.
15:47 mzki: and it's something I haven't tried before so trying to figure out if the card should be usable with nouveau in such a setup
15:47 imirkin_: you obviously won't have a display until nouveau loads though
15:47 mzki: yep
15:48 mzki: i think i should be able to live with that
15:48 imirkin_: also please don't read this as a guarantee of things working
15:48 imirkin_: unfortunately there's a lot of ... weirdness ... in the option rom stuff
15:49 mzki: sure, just trying to get some input
15:49 imirkin_: also unrelated to all that
15:49 imirkin_: some people have had issues with nouveau on GTX 660's. not sure if that extends to GTX 660 Ti's.
15:50 imirkin_: the issues were resolved by running blob firmware for context switching instead of nouveau-written firmware.
15:50 imirkin_: naturally the author of the firmware can't reproduce the issues, otherwise what fun would it be.
15:51 imirkin_: [since the firmware is in no way specific to a particular marketing name, it must be something odd with some boards, but we don't know what identifies the oddness]
15:51 mzki: from the CodeNames page, 660 Ti is GK104, while plain 660 is GK106, should the GK104 be more stable?
15:52 imirkin_: nope. it's all the same.
15:52 imirkin_: also the codenames page is more of a guide than absolute truth
15:52 imirkin_: marketing names are spread out pretty randomly
15:52 imirkin_: [esp for lower end stuff]
15:52 imirkin_: like ... a 630 can be a GF108, GK107, or GK208.
15:53 mzki: ok, in that case, are any cards less likely to give trouble, at similar performance level or is is all lottery?
15:54 imirkin_: well, i'd say 95% of keplers work well. but it's mostly a lottery.
15:54 imirkin_: just with high chances of success :)
15:54 imirkin_: if possible, stay away from "OC" cards as those have timings that upset our reclocking logic sometimes
15:55 mzki: ah ok
15:58 mzki: imirkin_: about the firmware, would you be able to point me to the source code or any info on it? trying to understand a bit more about how this all works
15:59 imirkin_: which firmware?
15:59 imirkin_: you mean the context switching firmware?
15:59 imirkin_: or the logic to init the board?
15:59 imirkin_: [which is not firmware]
15:59 mzki: the context switching firmware
15:59 imirkin_: [but people can get confused]
16:07 anEpiov: I use NOUVEAU(0) definately
16:15 imirkin_: mzki: https://github.com/skeggsb/nouveau/tree/master/drm/nouveau/nvkm/engine/gr/fuc
16:16 imirkin_: mzki: "compiled" with cpp, assembled with envyas.
16:17 imirkin_: this is to save engine execution context and load another one. kind of a context switch.
16:20 mzki: imirkin_: thank you
16:20 imirkin_: runs on a "cpu" inside the gpu
16:21 imirkin_: a similar cpu controls PMU functions, and another set of cpu's control video decoding/encoding hw.
16:22 mzki: what kind of "cpu" would that be?
16:22 imirkin_: falcon
16:23 imirkin_: G84 - G96 used xtensa cores for controlling the vdec stuff
16:23 imirkin_: but then they made their own
16:23 imirkin_: but basically you just load a little RTOS on them and interact.
16:28 mzki: imirkin_: and one last question i guess, you mentioned a driver parsing the init tables in the vbios, where does it get those init tables from, the actual hw it is initializing?
16:29 imirkin_: "places"
16:29 imirkin_: :)
16:29 imirkin_: https://github.com/skeggsb/nouveau/tree/master/drm/nouveau/nvkm/subdev/bios
16:29 imirkin_: have a look at shadow.c and the various options for where to get the vbios from
16:29 imirkin_: (and image.c? i forget)
16:36 mzki: imirkin_: cool, thanks for your help
16:38 imirkin_: on your board, most likely the PROM option is the one that would have it
16:38 imirkin_: i.e. shadowrom.c
17:49 karolherbst: imirkin: meh :( now we segfault in KHR-GL45.arrays_of_arrays_gl.SubroutineFunctionCalls1 due to spilling messup....
18:05 jayhost: What has nouveau been up to? Is there not much work to do because the new proprietary blobs?
18:11 karolherbst: jayhost: lack of time
18:12 imirkin_: more like no time being invested
18:14 jayhost: On nouveau part or Nvidia?
18:14 imirkin_: well there never was on nvidia's part
18:15 jayhost: What would you be doing if you had more time?
18:15 imirkin_: [at least not for desktop gpu's, except by coincidence]
18:16 imirkin_: find the blobs being uploaded on maxwell2+ and locate them in the package
18:16 imirkin_: rewrite the driver with threading in mind
18:16 jayhost: Difficulty? Is it worth it or do you think community should vote with wallet and get amd
18:17 imirkin_: well, there's no one to do this work
18:17 imirkin_: so really, people should just get amd
18:17 imirkin_: amd has a fully-staffed team behind the driver
18:17 imirkin_: there is no such team behind nouveau
18:18 imirkin_: [with apologies to skeggsb...]
18:18 jayhost: I know, you've told me, It just seemed like you karol and roy were still pretty active
18:19 imirkin_: i haven't done anything in a while
18:19 imirkin_: other than lots of hot air
18:19 jayhost: Are you hobbyist or you have real job / start up
18:19 imirkin_: not sure how the two are mutually exclusive
18:19 imirkin_: i have a real job
18:20 imirkin_: and i hack on nouveau as a hobby in my free time. except i've had none of late.
18:20 jayhost: When I said hobbyist I meant exclusively hobbyist :D
18:20 imirkin_: this is true of everyone else as well except ben, who works on nouveau at RH. except he ends up with RH responsibilities.
18:20 karolherbst: jayhost: well, if there is enough money to pay somebody full time, which is unlikely but mhh, that _might_ work, but then there is alot of overhead to this as well
18:21 karolherbst: my hope is, it would be better if there are two paid devs....
18:23 jayhost: Who would finance?
18:24 karolherbst: does it really matter?
18:24 karolherbst: maybe RH, maybe somebody else
18:25 jayhost: No, I just don't know much about financing OSS
18:26 karolherbst: well somebody who thinks that paying a dev working on OSS in its interest is worth the money, they usually end up hiring somebody or do contracting
18:27 karolherbst: benefit: they are able to shape the direction of that oss project
18:27 karolherbst: like: fixing bugs in the interest of that entity which pays
18:27 karolherbst: or creating new features
18:29 jayhost: Ah yes
18:31 jayhost: I hope I can figure out how to make $ from OSS. I've just been working on some open source shader code. https://pbs.twimg.com/media/DMdDAI5WAAYjyZI.jpg
18:32 karolherbst: jayhost: well, most of the time you need entities with a money interested in your project
18:35 jayhost: I saw Nvidia is allowing Morgan Mcguire to work on G3D while employed with them.
18:35 jayhost: CasualEffects
18:41 jayhost: It would be nice to convince them to spend a little on the Odriver although I take it they don't care.
18:44 imirkin_: until then, i just tell people to get amd
18:44 imirkin_: [or intel]
18:58 jayhost: It's really great having Vega and being able to use completely open stack without issue.
19:20 imirkin_: yeah. the amd guys are doing a great job
19:20 imirkin_: [and also a few very capable external contributors]
19:39 jayhost: What would it take to get 1050ti working with 3d accel, hours of work?
19:42 koz_: jayhost: Signed firmware.
19:51 jayhost: Phoronix says they published GP107 https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Signed-Firmware-Pascal
19:56 karolherbst: well yeah, and the gp107 firmware had a bug initially
19:57 karolherbst: jayhost: you need a version of linux firmware from april or newer
20:20 jayhost: Assuming no 3d accell there, will read up more on it
20:21 karolherbst: jayhost: well, why don't you just update your kernel and linux-firwmare and try it out, because it should work
20:22 jayhost: I don't have a 1050ti :P
20:33 jayhost: I find the 750-1050ti series interesting because of the power consumption / ability to add to used system
20:39 imirkin_: jayhost: they have yet to publish any firmware for pmu
20:41 jayhost: yuck
21:34 karolherbst: the heck... we have like 70 piglit regressions
21:34 karolherbst: double related ones
22:06 karolherbst: imirkin_: this is super weird, now all those double piglit tests fail with the fp64 patches. Allthough I use the same version of piglit + same version of mesa where it didn't
22:06 karolherbst: ohh, shader compilation failed, but why
22:06 karolherbst: ohhhh
22:06 karolherbst: debug build
22:06 karolherbst: annoying
22:08 imirkin_: ?
22:09 karolherbst: yeah well, for some reason we fail some patches when doing a debug build... but then I am not quite sure why it regresses with the fp64 enabling patches
22:11 karolherbst: uhm
22:11 karolherbst: I don't mean debug build
22:11 karolherbst: but O0 vs Ofast
22:11 imirkin_: oh, are you using buggy-clang?
22:16 karolherbst: gcc
22:16 karolherbst: but you know, compilers are allowed to change runtime behaviour in c++ with optimizations
22:17 karolherbst: like removing constructor calls
22:17 imirkin_: sure.
22:18 karolherbst: anyway, with Ofast it passes now
22:18 imirkin_: and O0 it doesn't?
22:18 karolherbst: yep
22:18 karolherbst: funky though, without the fp64 it passes on O0
22:18 karolherbst: *patches
22:18 imirkin_: so that means it's buggy
22:18 imirkin_: get valgrind on it
22:19 karolherbst: ohh, right
22:25 karolherbst: imirkin_: fun, memcheck doesn't show anything
22:38 karolherbst: meh
22:39 karolherbst: okay, I think I found it