00:30imirkin: ok ... some of those fixes pushed out. thanks for reviewing, hakzsam
00:30imirkin: will see if i can easily figure out the update_surface thing...
00:31imirkin: seems like after make_resident it can't change
00:33imirkin: hakzsam: "The error INVALID_OPERATION is generated by BufferData if it is called to modify a buffer object bound to a buffer texture while that texture object is referenced by one or more texture handles."
00:33imirkin: so i don't think the update_tic case can happen
00:34skeggsb_: imirkin: in a specific case, or, at all?
00:34imirkin: skeggsb_: in the case where that buffer is bound to a texture and that texture has a bindless handle allocated
00:35imirkin: allllthough..... /me needs to look
00:35imirkin: f me
00:36imirkin: the whole way for this to happen is when nouveau_buffer_transfer_map does it behind everyone's back
00:36imirkin: so yeah, i do need to do it.
00:36imirkin: or teach transfer_map to not discard.
00:36imirkin: unfortunately that won't be extremely easy
00:37imirkin: [without killing the whole discard feature in the first place]
00:37imirkin: skeggsb_: in case you're following along, that's the nouveau_buffer_should_discard() bit in there
00:37imirkin: nouveau_buffer_reallocate will then change buf->address around (and buf->bo)
00:39imirkin: ooooh, and i can use the invalidate_resource_storage trick.
08:04hakzsam: imirkin: with radeonsi, we have had to support buffers invalidation, because glInvalidateBufferSubData() is used instead
08:04hakzsam: and IIRC, the state tracker can invalidate buffers in some situations
08:07hakzsam: I mean, we create new buffers because it's better for perf (avoid a staging buffer), and the descriptor has to be updated accordingly
08:08hakzsam: I think it should be similar with nouveau
11:35imirkin: hakzsam: i suspect you can't call glInvalidateBufferSubData on a buffer that backs an image/texture that has a handle allocated
11:36imirkin: although the bindless spec makes no mention of it =/
11:36imirkin: feels like an oversight
11:36imirkin: although ... hrm. maybe not.
11:37hakzsam: pretty sure that DOW3 does it
11:37hakzsam: and Dirt Rally & friends
11:37hakzsam: especially because I hit that issue with radeonsi :)
11:37imirkin: heh ok
11:38hakzsam: should be doable though, just need to update the tic
11:38hakzsam: or create a new one
11:39hakzsam: you know, the bindless spec is not really clear in many ways..
11:42imirkin: i started doing it one way
11:42imirkin: but in the end decided my whole approach sucked
11:42imirkin: so i'm going to redo it a bit
11:43imirkin: esp taking into account what you said about having to clear out the bindless bin every time
11:43imirkin: since that's clearly a bad idea ;)
11:47hakzsam: especially because the main goal of bindless is to reduce driver overhead, not introduce more :)
11:49imirkin: but that will take probably another 2h of sequential effort. maybe tonight... but probably not.
12:44kattana: what's the state of vgpu?
12:47mupuf_: kattana: no further development, AFAIK
12:48mupuf_: check the github tree
12:50mupuf_: kattana: hmm, vgpu was the work of Shinpei Kato, right?
12:50mupuf_: I can only find stuff related to gdev
14:06ccaione: imirkin: just in case this rings a bell https://bugs.freedesktop.org/show_bug.cgi?id=101601#c2
14:06drsaars: Which graphic card gives most value for the money? I see that GeForce 8400 1GB (DDR3) is recommended by ThinkPenguin here: https://www.thinkpenguin.com/gnu-linux/geforce-8400gs-1gb-pci-express-20-video-card-gnulinux-full-low-profile-brackets. Are there better options with GDDR supported?
14:15karolherbst_: drsaars: many and most of those are not 8 years old
14:16drsaars: karolherbst_: Please mention a modern card with good nouveau support.
14:17Lyude: drsaars: if you are looking into getting a new card that's well supported under Linux I would recommend just going with amdgpu
14:18fomg-optimize: Or Intel
14:18fomg-optimize: They are quite good now, honestly
14:18Lyude: nouveau is very nice, but there are still many things it's missing that we can't really add right now because of nvidia being crappy
14:18Lyude: i run an r9 380 on my desktop and it works wonderfully
14:19orbea: yea, considering how smeg nivida are, nouveau does quite well. Unfortuantely that doesn't compare to amd/intel...
14:19fomg-optimize: I am stuck with nvidia in my laptop, so I want to say thank you to everyone working on nouveau by the way! Excellent work. Thank you!
14:19drsaars: fomg-optimize: Plese give me a good supported Intel card.
14:19Lyude: drsaars: all of them
14:19Lyude: well, except maybe some of the intel atom ones (cherryview)
14:20gnarface: that's not 100% true
14:20orbea: drsaars: ask in #intel-gfx maybe?
14:20Lyude: but they still work OK
14:20fomg-optimize: Just about to say that
14:20gnarface: i just discovered te G45 series lacks h264 support
14:20Lyude: gnarface: yeah but i mean, that's the G45
14:20gnarface: (apparently partial decode is available but the driver component wasn't finished)
14:20drsaars: I'm running Intel Core i7. Should I buy an Intel graphic card?
14:20gnarface: i'm just saying, the intel integrated video stuff is not all UNIFORMLY well supported, despite massive improvements lately
14:20Lyude: drsaars: no, the card comes built into the GPU. Just a question: what -are- you going to be doing with this card?
14:21Lyude: because if you're planning on trying to do gaming or anything you should go with an AMD GPU, for just normal workstation stuff intel will be fine
14:21drsaars: Lyude: Mining cryptocurrencies, use it as a workstation.
14:21Lyude: gnarface: true, but it's much more complete then most drivers
14:21Lyude: crypto... anyway, i would go with amdgpu then
14:22gnarface: drsaars: i think if you're mining there's no question AMD is the way to go
14:22Lyude: they will be hard to get your hands on but for mining they are as good as they come, even without taking linux into conidration
14:22drsaars: gnarface: Cool! Why?
14:22Lyude: they are better at opencl and friends
14:22Lyude: significantly better iirc. there are cuda miners that work pretty well but they still kind of get blown out of the water by amd
14:23gnarface: drsaars: without going into too much technical gibberish, basically a generations-old unique quality to their architecture style lends them very well to being reprogrammed for simple repetitive tasks like encryption/decryption
14:23gnarface: drsaars: enough so that at equivalent cost, the equivalent Nvidia hardware comes in roughly at around 1/4th the keyrates
14:23Lyude: again though: you will literally have trouble getting your hands on them at the moment, they're kind of selling out everywhere. but if you can find one that's going to be your best bet, you definitely don't want to be doing mining with nouveau
14:23gnarface: anywhere from 1/10th to 1/3rd probably
14:24Lyude: I think the 580RX might still be around
14:25drsaars: Why are they selling out?
14:25gnarface: people found out
14:25Lyude: drsaars: literally miners like you :P
14:25Lyude: nvidia isn't fairing much better there iirc
14:26gnarface: oh, there's a new crypto currency on the market with major corporate backing too. that may have increased the demand for new mining rigs
14:26gnarface: ethereum or something like that
14:26Lyude: yeah, ethereum is special because it's ASIC proof
14:26Lyude: so you can't cheat as saily
14:26gnarface: i think i also heard AMD was planning on dropping dedicated mining cards weren't they?
14:27gnarface: i don't know if it actually happened or was merely teased
14:27Lyude: maybe, that sounds more like a marketing gimmick though. Any headless GPU would work just fine for that, doesn't need to be "dedicated" to mining...
14:27drsaars: Why don't I want to mine with nouveau?
14:27gnarface: limited support for low-level hardware features required by mining, drsaars
14:27Lyude: drsaars: we don't have opencl and our performance isn't near that of the nvidia blob. the nvidia blob driver could probably mine pretty well, but you will still see better performance regardless just using AMD cards
14:27Lyude: we also don't have cud
14:28drsaars: So I better mine with my CPU?
14:28Lyude: no, an AMD GPU
14:28Lyude: CPUs are very slow at mining
14:29ytrezq: Hello, recent consumer NVidia cards added support for quad buffering for stereoscopic rendering, are there plans to support it ?
14:29drsaars: What about using an AMD GPU with nouveau to mine?
14:29ytrezq: (Pascal based)
14:29gnarface: drsaars: doesn't work that way.
14:29drsaars: gnarface: Ok.
14:30Tom^: otherwise the 780ti is probably the highest end card for nouveau that reclocks well no?
14:30gnarface: drsaars: nouveau is nvidia hardware-specific
14:30gnarface: drsaars: (just theoretically though, if it were possible, it would suck)
14:30drsaars: Ok, I refuse to not use noveau so I guess I have to wait with mining.
14:30Lyude: amd is far too different to ever use with nouveau :P
14:31Lyude: drsaars: why exactly...?
14:31Lyude: what do you need nouveau so badly for
14:31drsaars: Lyude: Well I refuse to use proprietary drivers.
14:31Lyude: drsaars: amd has open drivers that work just fine for this stuff
14:31Lyude: that is why I suggested then
14:31drsaars: Lyude: Is there free software drivers for AMD GPU's I can use for mining?
14:31Lyude: they have their own closed source drivers as well but amdgpu open source is a thing, I use it on my desktop even
14:32Lyude: drsaars: I -think-, my only question is whether or not the free drivers (e.g. gallium on mesa) support opencl
14:32Lyude: if they do then you should be all set for mining
14:34drsaars: Lyude: Thanks.
14:36Lyude: drsaars: np, good luck! lemme know how it goes
14:36Lyude: thinking of wasting some of my personal amd cards for crypto stuff. maybe
14:36drsaars: Lyude: So Nouveau is for Nvidia and Gallium3d is for AMD?
14:37Lyude: that's a bit complicated. so, imagine gallium as a kind of middlelayer that a lot of the open 3d drivers use
14:37drsaars: Lyude: Ok.
14:38Lyude: basically every GPU driver in mesa, other then intel because they're intel, uses gallium. It lets us write one driver for each platform, and have a working opengl/opengles/etc. driver
14:43Lyude: also, since this sounds like it would help. i965 = intel, amdgpu = AMD kernel drivers, radeonsi = AMD opengl/opengles/etc. drivers, nouveau = nvidia drivers
14:43drsaars: Lyude: How well supported is say AMD RX 580 (GDDR5) in Linux-libre?
14:43Lyude: drsaars: they'll all be pretty well supported
14:46drsaars: Lyude: 3D supported too?
14:48Lyude: drsaars: yes, opngl 4.5
14:48Lyude: and as of recently: vulkan as well
14:48Lyude: like I said though: double check mesa actually has an opencl driver for AMD
14:48gnarface: drsaars: commercial games have marginal AMD support on linux still generally, unfortunately. but it's getting better. it's an important caveat; if you'd said "gaming" not "mining" i'd have told you Nvidia hardware all the way, but i'd have also told you for now the only sane choice is to stick with the non-free driver too. with AMD you can still get some gaming done with open source
14:49Lyude: i mean, depends what you mean by "marginal"
14:49gnarface: hit&miss i mean
14:49Lyude: an opengl app is an opengl app, although some shaders may be more optimized for nvidia
14:49gnarface: it's great for some games, some games just crash because they're badly programmed
14:49Lyude: that is still a bug though :P
14:49gnarface: or fall back to software rendering
14:49Lyude: and thus, should be fixed
14:49gnarface: yes, it's definitely a bug
14:50gnarface: but it's important to note how widespread these types of bugs are right now for AMD users on the linux Steam catalog
14:50gnarface: shouldn't affect open source/libre software though
14:50gnarface: since they can keep up
14:50gnarface: but i'd definitely also recommend going with a 4.9 kernel or later, and a bleeding-edge mesa version
14:50gnarface: just based on the experiences of AMD Linux gamers i've talked to
14:51gnarface: that's actually the only reason i didn't switch to AMD this year
14:51gnarface: maybe next year though (hopefully)
14:51Lyude: gnarface: ah, i haven't hit any myself yet
14:52gnarface: i really wanted one of those 8GB RX 480's
14:52drsaars: Lyude: Thank you for being so specific.
14:52gnarface: they had a good sale from MSI
14:52gnarface: i was about to do it
14:52Lyude: drsaars: it is no problem
14:56drsaars: Lyude: How many GB RAM should the graphic card have for mining?
14:56Lyude: drsaars: i have no idea about any of that stuff, sorry
14:56drsaars: Lyude: Ok.
14:57gnarface: i would assume it doesn't need much ram but i don't actually know
14:57gnarface: for gaming though i'd say 6GB minimum for a new card these days
14:58gnarface: just because that's what the benchmark seems to be in new releases
14:58gnarface: i'm still doing fine with 2GB but it's a limitation
14:58gnarface: (can't play shadow of mordor)
15:00gnarface: myself i'm going 8GB next time around
15:00gnarface: to buy some future-proofing
15:01fomg-optimize: While we are talking about this, can I sneak in a question. What do I need to install in order to ensure that software capable of using opencl does so on nouveau
15:01fomg-optimize: I hope there will be no need for recompiling?
15:03gnarface: ocl-icd-libopencl1 or mesa-opencl-icd or something like that is my guess just comparing debian package names to the nvidia ones
15:04gnarface: there appears to be vendor-specific opencl libraries as well as generic mesa ones
15:04gnarface: this isn't something i've tried myself though
15:05gnarface: i wouldn't expect compilation was necessary, at least on debian derivatives, unless you were trying something bleeding-edge
15:05gnarface: arch might be a different story though, for example
15:07drsaars: Lyude: check this out: https://openbenchmarking.org/s/OpenCL%201.1%20Mesa%2013.1.0-devel&show_more
15:08fomg-optimize: gnarface, drsaars thank you
15:09drsaars: Lyude: "like I said though: double check mesa actually has an opencl driver for AMD" -- Can you please help me find any web link that can verify this for Linux-libre 3.13.0 x86. It would really help me.
15:12imirkin_: ccaione: very odd.
15:12pmoreau: drsaars, Lyude: Mesa does have an OpenCL driver for AMD, aka clover, however it only supports 1.1 (and part of 1.2 maybe). I have no idea which cards are supported though. Probably all cards supported by r600 and radeonsi.
15:12Lyude: drsaars: you will have to do some research on your own, I never have worked with opencl before. it looks like we support it but I'm not sure how much of opencl we actually support
15:14pmoreau: fomg-optimize: You would also need to implement OpenCL support in Nouveau, which is worked on but nothing is mainlined yet.
15:14drsaars: Lyude: Are you sure that it is critical that mesa actually has an opencl driver for AMD for effective mining?
15:14drsaars: Lyude: Ok.
15:14Lyude: either that, or if you can find a vulkan mineeer? not sure if vulkan works for compute stuff
15:18gnarface: drsaars: i'm gonna go out on a limb and say that Linux 3.13 is too old for ANY of the amdgpu stuff
15:18Lyude: you are correct
15:18drsaars: I expected that honestly.
15:18gnarface: drsaars: nobody i talked to managed to get one of those cards to work right on any kernels before 4.x something... maybe even 4.7 or 4.9
15:19gnarface: i feel like i heard someone got one working on 4.4 with some backported patching
15:19Lyude: backporting amdgpu patches sounds like cruel and unusual torture...
15:20drsaars: gnarface: Which cards? All modern ones?
15:27gnarface: drsaars: yea just the modern ones. i wanna say polaris and later? i'm not so hip on AMD video stuff, this is just anecdotes and hearsay from other users
15:28gnarface: maybe "polaris 10" not sure
15:29fomg-optimize: pmoreau, thank you for making it clear. much appreciated
15:29gnarface: but basically i think the class of AMD GPUs that the RX 480 is in, and the one generation prior to that
15:32imirkin_: ccaione: i'm not really in tune with the display stuff
15:32imirkin_: drsaars: gnarface: #radeon will be the better venue for discussing AMD-related items
15:33imirkin_: Lyude: why? just send them 4.12 and then apply a diff that changes the version to 3.13. everyone should be happy, i think.
15:33imirkin_: (that's basically what backports are, right?)
15:33Lyude: sorta. i mean, it depends how much you're backporting
15:33pmoreau: fomg-optimize: If you feel like it, you can always try this WIP: https://phabricator.pmoreau.org/w/mesa/testing_opencl_through_spirv/ But you do need to compile a specific version of Mesa, as well as LLVM and clang.
15:33Lyude: my experience from rhel has been it's far easier to literally copy paste the drm tree instead of trying to backport diffs because of how often drm changes (with good reason)
15:33imirkin_: people want a kernel that has all of 4.12's features, but that has a 3.13 label. oblige them ;)
15:34Lyude: which is why I am astonished chromeos manages to keep their kernels running like they do...
15:35imirkin_: ccaione: out of curiousity, what physical ports are available on your board?
15:36imirkin_: ccaione: oooohhh
15:36imirkin_: ccaione: i bet the ctrl/user channels are wrong
15:37imirkin_: have a look at the values in cursgp102.c
15:37imirkin_: last line... chid = ...
15:40fomg-optimize: pmoreau, I will read up on it and see if I have the time. Never used llvm, clang.
15:40fomg-optimize: pmoreau, thank you for giving me something to play with :)
15:41drsaars: imirkin_: Yes.
15:41pmoreau: fomg-optimize: Beware that there aren't many OpenCL features to play with, yet. Feel free to me ping me here to report missing instructions, errors, missing features.
15:43fomg-optimize: pmoreau, will do. again, thank you
15:44pmoreau: fomg-optimize: You're welcome :-)
15:46imirkin_: ccaione: do you have a mmiotrace of blob?
15:46imirkin_: that should tell you what channel the cursor stuff is meant to be done on
15:46imirkin_: (or maybe it's the overlay stuff that's broken)
15:47imirkin_: skeggsb_: sounds like those chid's changed on GP108 ... advice to ccaione for finding them?
15:47imirkin_: skeggsb_: are they in the vbios somewhere perhaps?
15:49drsaars: Lyude: "Probably the most interesting feature of the GNU Linux-libre 4.2 kernel is the addition of support for AMDGPU, the AMD GPU LLVM (formerly Low Level Virtual Machine) backend. However, it would appear that AMDGPU doesn't work at all without blobs, similarly to the Radeon driver. GNU Linux-libre kernel 4.2 also adds a freedom-friendly Intel i915 driver." - http://news.softpedia.com/news/gnu-linux-libre-kernel-4-2-officially-rele
15:49drsaars: Lyude: Bad news.
15:49Lyude: that is wrong
15:50Lyude: oh 4.2
15:50Lyude: probably, but why are you using old kernel versions?
15:50Lyude: "4.2 also adds a freedom friendly i915 driver" i am pretty sure i915 definitely predates 4.2
15:54drsaars: Lyude: Do you know any good Intel i915 graphic card?
15:55drsaars: Lyude: I'm not particularly familiar with graphic card chipsets.
15:57Lyude: drsaars: you reallllllllllllllllly don't wanna do i915 for mining, I'm warning you :(
15:57drsaars: Lyude: Lol, ok?
15:57Lyude: regardless: there's not much to say there, the iris GPUs are the best one but remember it's all what's packaged with the CPU, the intel GPUs aren't a seperate thing and usually aren't nearly as powerful as amd or nvidia
15:59drsaars: Lyude: It seem like there are no 100% libre solution to effectively mine cryptocurrencies with any graphic card then.
15:59Lyude: yeah, sorry :\. open compute has a long ways to go
15:59drsaars: Lyude: I'm fine with that. I'm just saying.
15:59Lyude: yeah, it'll get there someday
15:59Lyude: if we managed open gfx I'm sure we can do compute eventually :)
16:00gnarface: nothing without some hand wiring at least
16:00gnarface: didn't someone make a decent crypto currency mining rig out of a few stacks of hand-wired celeron 300A's on fpga->slot 1 daugher cards?
16:00gnarface: i thought i heard that was a success
16:00gnarface: maybe it was just a joke though
16:00Lyude: that sounds like the phi
16:01ccaione: imirkin_: yup, I have the mmiotrace
16:01imirkin_: ccaione: can you put it up somewhere?
16:01ccaione: sure I can
16:03drsaars: Lyude: "[17:50] <Lyude> probably, but why are you using old kernel versions?". I asked in #linux-libre, they said that "[17:50] <jxself> The first question I'd wonder is if the situation with the blobs has changed. As far as I know it has not."
16:03imirkin_: hrm odd. nouveau 0000:01:00.0: disp: ch 15 init: 00000081
16:03Lyude: you only need the blobs for full opencl from what i found
16:04Lyude: opencl kinnnnnnda runs on mesa with clover it seems but not entirely
16:04Lyude: everything else you most definitely do not need the blob for though
16:04Lyude: heck, you might even be able to use the amdgpu-pro opencl stack while using the open source amdgpu kernel driver
16:05drsaars: Lyude: Do you suggest a libre-solution?
16:05imirkin_: i don't understand where that 15 comes from.
16:06Lyude: drsaars: for open compute? at the moment, no
16:06ccaione: imirkin_: https://bugs.freedesktop.org/show_bug.cgi?id=101601#c3
16:06drsaars: Lyude: That is the only thing I care about.
16:06Lyude: yeah, I can't help you there. sorry :(
16:07drsaars: Lyude: Thank you anyway.
16:16ccaione: weird indeed
16:17ccaione: in the first log (journal trace GP108) we have nouveau 0000:01:00.0: disp: ch 19 init: 00000081
16:20imirkin_: so ... i see chid's of 9, 13, 17 for pioc
16:21ccaione: same here
16:21imirkin_: return nv50_disp_chan_new_(func, mthd, root, ctrl + head, user + head,
16:21imirkin_: you have too many heads!
16:22imirkin_: ccaione: can you make a dmesg with nouveau.debug=trace ?
16:22ytrezq: Hello, recent consumer NVidia cards added support for quad buffering for stereoscopic rendering, are there plans to support it ?
16:22imirkin_: ytrezq: i don't think anyone here is familiar with what specifically they added that wasn't previously available in GPUs from, say, 10 years ago
16:22ccaione: imirkin_: it's this one already https://bugs.freedesktop.org/attachment.cgi?id=132255
16:22imirkin_: ccaione: right
16:23imirkin_: nouveau: DRM:00000000:00009870: ioctl: create disp cursor vers 0 head 2
16:23imirkin_: ccaione: so it works for head 0 + 1
16:23imirkin_: but it doesn't work for head 2
16:23imirkin_: my guess is that GP108 is limited to 2 heads
16:23imirkin_: unlike the others which can have up to 4
16:23ytrezq: imirkin_: I would say oe year
16:23ytrezq: imirkin_: I would say one year ago
16:24imirkin_: ccaione: this must be encoded somewhere, but for the benefit of your system, you can just change a hardcoded 4 somewhere into a hardcoded 2
16:25ytrezq: imirkin_: This is for knowing if there will be hardware support for developping OpenGl games with stereoscopic support
16:25ccaione: imirkin_: ok, soooo, I'm not really familiar with nouveau code, where exactly?
16:26imirkin_: ytrezq: my point is, i don't think there's been any hw change to *allow* it... some GM20x chips and newer have added various shader-level features which make it a little more effective
16:26imirkin_: ccaione: working on it ;) i'm not so familiar either
16:26imirkin_: i think i know, but i need to double-check
16:26ccaione: imirkin_: thank you very much
16:27ytrezq: imirkin_: I tested the change with Direct3d on Windows. The d3d api for stereoscopic rendering now works correctly (I’m not talking about 3dvision or 3d tv play)
16:27imirkin_: ytrezq: that's software features though
16:28imirkin_: i don't think any hw change has happened
16:29gnarface: ytrezq: bonus points if you can make it work in wine too!
16:29imirkin_: ccaione: gah! u32 heads = nvkm_rd32(device, 0x022448);
16:29imirkin_: ccaione: ok, in gf119_disp_new_, change it to heads = 2
16:29imirkin_: ccaione: did you have that mmiotrace somewhere?
16:29imirkin_: (did i miss your post about it?)
16:30ccaione: imirkin_: mmiotrace https://bugs.freedesktop.org/show_bug.cgi?id=101601#c3
16:32ytrezq: gnarface: you got my point, if the nouveau driver doesn’t support quad buffering for consumer cards like gtx 1070, then some Windows games will, well, till require a purchsed Windows copy from Microsoft.
16:32ytrezq: as they won’t work fully with wine
16:33gnarface: i'm not even sure Nvidia's official driver supports the 1070 fully in linux yet though
16:33gnarface: i thought i was hearing about showstoppers with some 1060 models still as recently as last week
16:35drsaars: "amdgpu = AMD kernel drivers, radeonsi = AMD opengl/opengles/etc." Is radeonsi not developed any more and/or is it outdated? Lyude:
16:35ytrezq: gnarface: not only they don’t support it. They also won’t do it, leaving Windows® as the only option for stereoscopic rendering for non quadro cards. That’s why I’m asking about nouveau
16:36ytrezq: (they only support it on Windows®)
16:38imirkin_: well, not like this is an indication of correctness, but....
16:38imirkin_:  527.965530 MMIO32 R 0x02245c 0x00000002 PUNITS+0x5c => 0x2
16:38imirkin_: perhaps it moved ;)
16:39ccaione: well, putting heads = 2 doesn't seem to work either, still getting timeout on nouveau 0000:01:00.0: disp: ch 19 init: 00000081
16:39imirkin_: anyone have a GM20x or newer board and can do a 'nvapeek 2245c' for me (and let me know what board it is)
16:40imirkin_: ccaione: also do it here: nv50_display_create
16:40gnarface: that's newer than mine, isn't it?
16:41imirkin_: ccaione: look for "create crtc objects to represent the hw heads"
16:41imirkin_: gnarface: no clue what you got
16:41gnarface: VGA compatible controller: NVIDIA Corporation G92 [GeForce 9800 GTX+] (rev a2) < this is older than G20x, i'm assuming?
16:41ccaione: imirkin_: yeah, always setting crtcs = 2, right?
16:41imirkin_: gnarface: just a tad
16:41imirkin_: ccaione: yes.
16:42gnarface: imirkin_: this one too, right? VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 650 Ti Boost] (rev a1)
16:42imirkin_: gnarface: GM20x = 2nd-gen maxwell. G92 = first-gen tesla
16:42gnarface: ok, so by 20x you mean 200+?
16:42imirkin_: gnarface: GK106 = kepler. closer, but still no - i assume that one is the 22448 register.
16:42imirkin_: gnarface: i mean GM20x, i.e. GM200, GM204, GM206
16:43gnarface: drat, that's all i've got on hand at the moment that i have permission to use
16:43gnarface: in theory a 1060 would be new enough though?
16:43imirkin_: and GM20x+ means also GP10x as well (since that's newer than GM20x)
16:43imirkin_: gnarface: yes
16:43imirkin_: gnarface: that's a GP106 iirc
16:44imirkin_: gnarface: https://nouveau.freedesktop.org/wiki/CodeNames/
16:44gnarface: ah ok
16:45ccaione: imirkin_: hell, that worked
16:45imirkin_: ccaione: can you confirm the output of 'nvapeek 22448' and 'nvapeek 2245c' for me?
16:45gnarface: hah NV01 Diamond Edge 3D Supported by vesa driver
16:45gnarface: i actually had one of these
16:45ccaione: imirkin_: with the nvidia blob? give me 3 min
16:46gnarface: and a NV03 too
16:46imirkin_: ccaione: no
16:46ccaione: oh, ok
16:46imirkin_: can do it on nouveau
16:46imirkin_: it's values that are "burned into" the gpu
16:46ccaione: 00000004 and 00000002
16:47imirkin_: ok, as expected. thanks!
16:47imirkin_: so the question is whether the # of heads is in 2245c now instead of 22448, or there's some other reason why heads 2 + 3 don't work for you
16:48gnarface: i've had weird behavior with different vendor's cards that changed depending on bios version even some times, with regards to which outputs the card actually acknowledges and activates being affected at cold power-on time by which ones have powered-on displays connected
16:48ccaione: good question, also I can cook a downstream patch but what about an upstream fix?
16:48gnarface: sometimes it would even change which was seen as the first/default physical output, even
16:49gnarface: (that's how i once confused a dead monitor for a dead video card - happened with that G92 in fact )
16:49imirkin_: ccaione: requires more investigation
16:49imirkin_: ccaione: to figure out how the blob determines the number of heads
16:50ccaione: got it
16:50imirkin_: i.e. look at what those nvapeek's return on other hw with 4 "real" heads
16:50imirkin_: and also pour over the mmiotraces to see what register the blob reads before making its decisions
16:56ccaione: imirkin_: weirdly enough in the log I still have timeout https://paste.fedoraproject.org/paste/9WUEQZOItUyxqGQbijhCpQ
16:56ccaione: but modesetting is working
16:58drsaars: lxo: Is radeonsi fully supported in Linux-libre?
16:58drsaars: Wrong chan, sorry.
17:01ccaione: imirkin_: can you kindly update the bugzilla with your findings? it would be really usefull and I'm not sure I have the full clear picture
18:04karolherbst: imirkin: I will try to figure out which draw command causes the timeout in F1, maybe it will take me just a day or so :/ or is it already known which shader causes this?
18:09imirkin_: karolherbst: i think it's known
18:09imirkin_: hakzsam did a ton of analysis on it
18:11imirkin_: ccaione: that's expected -- we don't bring up acceleration properly, the falcon never comes up
18:23karolherbst: imirkin_: do you know if that's written down somewhere?
18:23imirkin_: not sure, sorry
18:24karolherbst: at least I see nothing in trello or bugzilla
18:26hakzsam: IIRC, it was an infinite loop inside a compute shader
18:26hakzsam: but I could be wrong because the issue is still unfixed
18:26karolherbst: yeah, well, sure, but it would be nice to know which one
18:26hakzsam: good luck :)
18:26hakzsam: I don't remember
18:26karolherbst: I have a 55GB trace here
18:26karolherbst: will be fun
18:27hakzsam: it hangs during loading
18:27hakzsam: the trace should be small
18:27karolherbst: it loads like for 5 minutes here
18:27karolherbst: maybe I should do it again with the shader cache
18:33hakzsam: karolherbst: https://people.freedesktop.org/~hakzsam/
18:33hakzsam: try that one
18:33hakzsam: quite old, but you should be able to reproduce
18:35karolherbst: thanks, will try that out
18:56karolherbst: hakzsam: that trace works fine, thanks
18:56karolherbst: note to myself: don't trace at fullhd
19:03karolherbst: which OpenGL calls do I have to check for compute shader invocations?
19:48karolherbst: hakzsam: okay, it would be nice if you write a note beside the trace with this: "glDispatch at 1535203 doesn't cause timeout, draw at 1535389 does" or something along those lines
19:48karolherbst: so that this kind of information doesn't get lost
19:56karolherbst: actually it timeouts after 1535268 already, but I am pretty sure it's that compute shader at 1535203
19:57karolherbst: would like to write a shader_test file from this to cause a hang, mind wanna help me out with writing a proper test?
20:09karolherbst: okay, that draw at 1535389 makes the timeout to appear
21:20r3m: Hi, the nvidiga geforce 970 is now supported?
21:23pmoreau: r3m: It is. I don’t remember which kernel version is needed for it
21:23r3m: is it recent, I think I checked in 2015 to see if it was supported but it was not
21:23pmoreau: r3m: https://nouveau.freedesktop.org/wiki/ the first news item: kernel 4.12 is needed
21:23r3m: thanks a lot pmoreau !
21:24pmoreau: So, 4.12 should be released next week, or the week after.
21:25r3m: this is awesome very happy to heard that, I have no "real" problem with the nvidia proprietary driver but I prefer to have nouveau
21:29imirkin_: 970 is supported since a while... the 4GB ones were only recently fixed
21:32pmoreau: Were there non-4GB 970s?
22:04imirkin_: skeggsb_: good morning
22:06RSpliet: imirkin_: theory: 0x22448 vs 0x2245c could be links vs. heads? Bet it's something in this direction...
22:06imirkin_: RSpliet: it could be that 2245c is totally unrelated to display ;)
22:06imirkin_: 2 isn't such an "odd" number to have as a random PUNITS thing
22:07RSpliet: This I can't deny either. I assumed you found them in close proximity in traces (inceasing the likelihood that it's the same function in the blob reading both)?
22:07imirkin_: not close enough proximity
22:07imirkin_: blob doesn't look at 22448 in that trace
22:08skeggsb_: what's 612004 say btw?
22:08imirkin_:  527.212515 MMIO32 R 0x612004 0x30700f03 PDISPLAY+0x2004 => 0x30700f03
22:08skeggsb_: i'd say 22448 is either gone, or moved for some reason
22:08skeggsb_: yeah, that says 2 heads
22:08skeggsb_: (bits 3:0)
22:09imirkin_: well, 22448 does return 4
22:09imirkin_: so it's still there :)
22:10imirkin_: just not the number of heads, apparently
22:10skeggsb_: right, well, we may want to start obeying 612004 for heads like i recently added for ORs
22:10skeggsb_: it might still mean heads, just "register space reserved for 4 heads, but head 2+3 are disabled"
22:11imirkin_: and naturally they'll come out with boards where heads 0+1 are disabled...
22:11skeggsb_: yeah, that's what why i had to add it for ORs
22:11imirkin_: i was just kidding about that
22:11skeggsb_: most gf119+ boards have "3 DACs reserved, but only DAC1 present"
22:11skeggsb_: as in, DAC0 + DAC2 are missing
22:14skeggsb_: i still need to change the remaining places that use dac.nr/sor.nr/pior.nr to use the encoder list instead.. haven't yet, because there's no (obvious) sign the GPU cares... but nvidia don't touch the non-existent ones, so we probs shouldn't either
22:15skeggsb_: it cared for one spot where we wait on a value, which is already fixed by the change i made
22:16imirkin_: i assume having holes in the heads array would be !great?
22:16skeggsb_: we create it as a list already
22:17imirkin_: so could we just check before creating the heads?
22:17skeggsb_: yeah, see the OR commit I did, pretty sure the head changes would be identical
22:17skeggsb_: (except the bitfield to check)
22:17imirkin_: right, it'd just be (1 << id)?
22:17imirkin_: and that's for gf119+?
22:18skeggsb_: also, i don't think, based on the info nvidia gave me, that the pre-gf119 version of that reg has bits for heads at all, so, ignore that
22:33kattana: this good? --> gtx 660
22:34skeggsb_: depends if you get one of the ones nouveau likes, or not.. mine works great, there's some people that have random hangs for unknown reasons
22:35kattana: skeggsb_: I need it for passtrough
22:35kattana: on the 8x lane
22:38r3m: Hi, the gtx 970 is maxwell or pascal? it is in the nv110 so maxwell but in the news section we can read Fix for GTX 970 with 4GB VRAM and 2D/3D acceleration support for Pascal headed for Linux 4.12.
22:40kattana: skeggsb_: what type of hangs?
22:40skeggsb_: random ones, for unknown reasons... not all boards experience it
22:41kattana: skeggsb_: which one don't?
22:41skeggsb_: as i said, unknown. same chipset, same revision, some work, some don't
22:41skeggsb_: it'd be fixed by now if we knew more :P
22:42pmoreau: r3m: It is a Maxwell.
22:43r3m: pmoreau: oh i didnt read the and
22:43r3m: between vram and 2d/3d lol
22:43pmoreau: No worries
22:48pmoreau: fomg-optimize_: I just realised that the instructions are failing to mention SPIRV-Tools is a dependency. I’ll update them tomorrow.
22:50fomg-optimize_: pmoreau, thanks for the heads up. I have not had the time to look at it properly yet
22:51pmoreau: Sure, I just wanted to warn you in case you were going to look at it before I fix the instructions.
23:22imirkin_: skeggsb_: will you take care of the heads thing?
23:38imirkin_: skeggsb_: i'm thinking something like http://paste.debian.net/973628/
23:39imirkin_: oh, and probably change gf119_disp_new_ too
23:41imirkin_: ccaione: see if this helps? --^