07:58 mlankhorst: skeggsb: repoke, did you look at the rebased on older kernel atomic disable_all patch I sent you in pm?
08:17 skeggsb: mlankhorst: i haven't had time to test it. it looks like it achieves the same result as what nouveau does though
08:17 skeggsb: mlankhorst: any reason you can't plug in a nv board and test it?
08:18 mlankhorst: see pm
08:19 mlankhorst: but ack is enough, I can test the code works :)
08:21 skeggsb: the only reason nouveau overrode it was to get cleanup_fb() called, so framebuffers got unpinned and evicted from vram
08:22 mlankhorst: yeah
08:22 mlankhorst: I need it for the same reason on i915
08:22 skeggsb: well, you've got my ack in that case :P
08:23 mlankhorst: ok thanks
12:38 dboyan: imirkin, imirkin_: I tried compute shader on a 340 series driver and a vertex shader on 375.26, they are generating the same long code for drcp
12:38 dboyan: but I think I nearly understand what the blob is doing
12:42 dboyan: the blob "normalize" double to a small range, convert it to float and do rcp with 1 newton step, convert back to double and do 3 newton steps
12:44 dboyan: the latter 3 steps I'm not very sure, the last two steps seems transformed by optimization, not very straitforward
12:44 dboyan: *straightforwar
12:44 dboyan: *straightforward
12:45 dboyan: well, float is better than top half of double in that it has 3 more bits of mantissa
12:48 dboyan: still working out to understand the part to handle denorm result
13:35 imirkin: dboyan: note that we have library functions (check the codegen/lib directory) which you can use for such sequences
13:45 dboyan: imirkin, i see there are placeholders for xxx_rcp_f64 and xxx_rsq_f64. I assume the task is to fill in those routines and wire them up elsewhere?
13:46 imirkin: dboyan: either that, or adjust the lowering
13:46 imirkin: see lowering_nvc0::LegalizeSSA::handleRCPRSQ or something
13:46 imirkin: (going from memory)
13:49 dboyan: i know, if only one Newton-Raphson step is needed, i guess writing lowering in IR may be a better choice. For a complicated routine like this, though
13:50 imirkin: yep, your call
13:50 imirkin: you can see why i didn't do it given the current logic
13:50 imirkin: fwiw i did also have a patch doing a newton raphson step or two
13:50 imirkin: dboyan: https://github.com/imirkin/mesa/commit/867530da9b740fbad47e8d17e4489932b1523c29
13:50 imirkin: i never merged it because i couldn't find any test cases where it mattered
13:52 dboyan: Is there something to check the precision like piglit or CTS?
13:52 imirkin: there is in VK-GL-CTS now
13:52 imirkin: fp64-case2 or something, i forget
13:53 imirkin: but we should use the algorithm that nvidia follows
13:53 imirkin: however don't just copy their code
13:53 imirkin: write down the algorithm
13:53 imirkin: and then implement the algorithm independently
13:53 imirkin: last thing i want is magic steps along the way
13:55 dboyan: yeah, i'll definitely write my own if i eventually implement that
13:56 dboyan: i had just wrote some C code to simulate that, and found some of the path would never be hit
13:57 dboyan: but i'm just curious what precision can be achieved by some simple newton-raphson steps
14:00 dboyan: imirkin, by the way, how do I calculate sched data if I were to write assembly code for kepler
14:31 imirkin_: dboyan: "carefully" :)
14:32 dboyan: ok, got it :)
14:33 imirkin_: and keep in mind, this thing has to play nice with ALL doubles, including infinities, nan, etc
14:37 dboyan: I know, a big portion of blob code deal with denorm. inf and nan are simpler, at least for rcp
14:38 imirkin_: and +/-0
16:39 nv40: imirkin: did i have to send the huge apitrace on such a simple and basic and always appearing error like this? https://pastebin.mozilla.org/8978789
16:39 imirkin_: no
16:40 imirkin_: are you using a recent mesa version?
16:47 nv40: imirkin_: OpenGL version string: 2.1 Mesa 13.0.4
16:47 imirkin_: hm, that should be fine
16:48 imirkin_: well, either way, iirc i was aware of issues that STK hits
16:49 nv40: how to reproduce this nv40 error: download and install lubuntu daily image (latest kernel, mesa, ...) apt-get update && apt-get install supertuxkart. start supertuxkart -> freeze
16:49 imirkin_: yea
16:51 nv40: should i provide some additional information? I have installed extra lubuntu to find a nv40 bug that is not based on plasma or gnome
16:51 imirkin_: nope
16:51 imirkin_: the nv30 gallium driver has a lot of issues
16:52 imirkin_: in this particular case, i think there's an issue in incompatibility of color and depth formats
16:52 imirkin_: as well as running out of vram
16:53 nv40: would you like me to test some patch or would you plugin your own nv40 card?
16:54 imirkin_: i would, eventually, plug in my own nv4x. i don't have any patches for you to test.
16:54 imirkin_: if you're looking to use open-source drivers, i'd recommend radeon. otherwise nvidia's blob drivers should work nicely. they recently updated the 304.x release for Xorg 1.19.
16:55 nv40: ok. any plans on fixing this? i have reported this about 1,5years ago and waiting since then
16:55 imirkin_: no specific plans.
16:55 nv40: imirkin_: there are critical R600 error that let crash my system with kernel 4.9.9
16:55 nv40: and all kernels before of course
16:56 imirkin_: of course :)
16:57 nv40: imirkin_: are you interested into R600 VDPAU errors? I could provide logfiles
16:57 imirkin_: i thought those just got fixed
16:57 imirkin_: either way, i'm not super-familiar with r600 vdpau
16:57 imirkin_: you might talk to people in #radeon
16:57 imirkin_: who tend to be helpful
16:58 nv40: they are blocking unregistered irc users AND they are blocking webchat users. This irc chat here is not blocking me reporting bugs
16:58 imirkin_: ah. probably because of joss =/
16:58 imirkin_: some stupid troll who comes in and spouts nonsense, and almost always via webchat
16:59 imirkin_: i've resisted the temptation to just nuke all of webchat in here
16:59 nv40: could you maybe unblock registering? You probably know the people there. i can use other webchat to get there
16:59 imirkin_: so instead i have tons of bans for his various bounce servers
17:00 imirkin_: mmm... airlied agd5f --^
17:02 nv40: can you show me what you mean with those VDPAU problems were fixed? I have not read anywhere anything about that
17:03 nv40: What also didnt seem to work is VA-API on R600. Should VA-API work with R600?
17:03 imirkin_: mmmmmaybe
17:03 imirkin_: that seems less likely.
17:04 imirkin_: nv40: https://bugs.freedesktop.org/show_bug.cgi?id=98512
17:04 imirkin_: perhaps your issues are different.
17:06 nv40: imirkin_: https://bugs.freedesktop.org/show_bug.cgi?id=98738
17:07 imirkin_: did you try the suggestion to disable dri3?
17:07 nv40: i have exactly this problem
17:07 imirkin_: and include a trace with debug symbols?
17:09 nv40: i also didnt know how to do this debug symbols thing
17:10 whompy: You could file or ping a bug. They're quite responsive normally.
17:12 nv40: whompy: when you send a message to a existing bug, does this message create a separate notification on some developer board or wont they see this message?
17:13 kattana_: what does it mean re-clocking in 4.10? quieter fans perhaps?
17:13 imirkin_: an email gets sent to dri-devel@ or mesa-dev@ depending on the bug setup
17:14 imirkin_: kattana_: it means that as an end user you can make changes to which perf level is active. otherwise you just get whatever you booted to.
17:14 imirkin_: (this involves changing various clocks to the perf level's parameters, which is why it's known as reclocking)
17:14 kattana_: imirkin_: is 'ondemand' there?
17:15 imirkin_: kattana_: there is no automatic reclocking, only manual
17:15 kattana_: ok thanks
17:15 imirkin_: but hey - better than none ;)
17:15 kattana_: imirkin_: can it be change on the fly?
17:15 imirkin_: yeah, you just echo stuff into a file in debugfs
17:16 imirkin_: and hope the gpu doesn't hang, which there's a very small chance that it might if you're driving screens off of it
17:16 kattana_: imirkin_: excellent, I just need two, non-gaming, and occasional gaming.
17:17 imirkin_: kattana_: you have a GM107 right?
17:17 nv40: how can i find out what mesa release incude this commit? https://cgit.freedesktop.org/mesa/mesa/commit/?id=322483f71b068b3bbf69e5434e888f3fd3f4589e
17:17 imirkin_: nv40: mesa 17.0.0 should have it
17:18 imirkin_: (you find out by running 'git tag --contains the-commit-id')
17:18 imirkin_: oh, and maybe a 13.0.x does too
17:18 imirkin_: let's see...
17:18 nv40: because its a bugfix shouldnt it also be inside of 13.0.4 ?
17:19 imirkin_: yep - it's also in mesa 13.0.1+
17:19 nv40: and also 12.0.6
17:19 nv40: ?
17:19 imirkin_: [as commit id f7efc0f0fcc6920b46daa8ce73fcba6d76415411]
17:19 imirkin_: doesn't seem to have been backported to 12.x though
17:19 nv40: ok, 13 is enough
17:20 nv40: thanks :)
20:10 NanoSector: does the 980 Ti have issues on Linux with both proprietary and nouveau?
20:11 imirkin_: i don't think such a generic answer can have any answer other than "yes"
20:11 imirkin_: s/answer/question/
20:11 NanoSector: as in black screens and stuff
20:12 imirkin_: afaik modesetting should work fine
20:12 NanoSector: if i got a penny for every time i heard 'nvidia' in combination with 'issue' in #antergos i'd be filthy rich by now
20:12 imirkin_: that said, it's much less tested than earlier gens
20:12 imirkin_: and there are a lot more weird setups possible with newer hw, what with DP-MST, etc
20:13 imirkin_: or HDMI 2.0
20:17 nv40: Just sell the crappy 980ti card and get a propper 780 Ti or a Titan Z.
20:18 NanoSector: not my card, someone was having issues with it
20:18 NanoSector: figured i'd ask
20:19 imirkin_: or get an AMD gpu, which will get actual support from people who are paid to work on it...
20:19 NanoSector: right
20:33 nv40: (radeon driver - paid mostly by the company that produces the hardware. Not by some other company - thanks Red Hat)
20:37 nv40: imirkin_: what is the state of SLI support? Is there something done about that in 2016 or 2017?
21:40 imirkin_: nv40: no support. unlikely to ever materialize.
21:40 Calinou: SLI is dead already, I believe...
21:40 Calinou: unless you're doing GPGPU
21:40 Calinou: for what it's worth, radeon does not support CrossFire either
21:42 karolherbst: Calinou: why is it dead already?
21:43 karolherbst: if I wouldn't have anything better to do, I would actually try to RE it, allthough this is like super low priority
21:44 imirkin_: actually the SLI bits are mostly RE'd i think
21:44 imirkin_: however the question is ... what to do with it
21:44 karolherbst: we have a 690
21:44 karolherbst: so we could just try things out I guess
21:44 imirkin_: i mean - automatically splitting the load amongst multiple GPU's ain't so easy.
21:44 karolherbst: ohh
21:44 karolherbst: no, the first step is to do offloading through SLI I suppose
21:44 karolherbst: just make it usable
21:45 karolherbst: and if we are able to use SLI as a fast transport between both GPUs, we can think about how to split one GL context on both
21:45 imirkin_: one nice thing about SLI is that it lets you share a single command stream among multiple GPUs
21:46 Calinou: stuttering is still a problem with SLI, so a single GPU is always a better solution
21:46 Calinou: people are starting to understand this, at least for gaming purposes
21:46 imirkin_: you can tag certain commands to execute only on the master or the slave
21:46 karolherbst: ohh, nice
21:46 imirkin_: and the rest execute everywhere
21:46 MrRooks: Does anyone have any suggestions on how to get the antergos live iso to boot with an nvidia 980ti? I tried blacklisting nouveau and also adding nomodeset on boot but I just end up with a black screen or a black screen with a cursor
21:47 imirkin_: MrRooks: does the screen turn on during boot and then turn off later?
21:47 MrRooks: in some configurations, yes
21:47 karolherbst: imirkin_: afaik there are some laptops with SLI connections between the two nvidia gpus, which can actually do _real_ SLI allthough both GPUs aren't strictly the same
21:48 imirkin_: MrRooks: in such a configuration, booting with nouveau.modeset=0 should get you a screen...
21:49 MrRooks: imirkin_: with the default boot options the monitors go off
21:49 MrRooks: ok I will try that now thanks
21:52 MrRooks: imirkin_: that seems to give me a similar result to adding 'nomodeset' which is just a blinking _
21:52 imirkin_: ah, well that's expected
21:52 imirkin_: sounds like things are working then ;)
21:53 imirkin_: chances are the antegros distro isn't set up to handle a no-modesetting setup?
21:53 imirkin_: ideally you can switch tty's to a VT with a shell on it
21:53 MrRooks: I found the 'nomodeset' tip on the antergos forums :(
21:54 imirkin_: perhaps they ship an nvidia driver, and that driver is too old to handle your gpu?
21:54 imirkin_: you need to get help from someone who knows something about your distro
21:54 MrRooks: yeah I was in there and someone said I should ask here :P
21:55 imirkin_: that said, GM200 should work fine with recent kernels on nouveau. i'm surprised it doesn't.
21:55 MrRooks: yeah 980ti isn't exactly something new
21:55 imirkin_: do you have a weird screen configuration?
21:55 karolherbst: dmesg might help
21:55 imirkin_: well - not a ton of people running nouveau on those.
21:56 MrRooks: 2 monitors, nothing crazy I don't think
21:56 imirkin_: are they chained via DP-MST?
21:56 imirkin_: do you know what kernel antegros is shipping?
21:56 MrRooks: not chained
21:57 MrRooks: both are display port but they are ran individually to the GPU
21:58 imirkin_: try unplugging one and see if nouveau fares better
21:59 MrRooks: same result
22:00 MrRooks: oh well, I guess I wil lwait for the next antergos iso release and go from there
22:00 MrRooks: thanks for your help