00:02karolherbst: imirkin: ohh, chromium uses a compat profile?
00:03karolherbst: didn't know that
00:03karolherbst: or maybe it is just their crappy reporting
00:09karolherbst: nice, webgl demos crashing the GPU, nice
02:43imirkin: did this get fixed at one point? https://hastebin.com/mayukoxilo.makefile
02:44imirkin: skeggsb: btw - confirmed that my hdmi2 code works on GM20x.
02:44imirkin: (or at least GM206)
02:44karolherbst: I think so
02:44karolherbst: I had it at some point, but not anymore
02:45imirkin: karolherbst: this is with 4.18.5
02:45imirkin: so not exactly ancient
02:45karolherbst: it was some kind of regression
02:45karolherbst: I hit it like one or two months ago
02:46imirkin: btw - fan1: 0 RPM
02:46imirkin: i shouldn't be worried right? (GM20x)
02:47karolherbst: but normally no
02:47karolherbst: does the fan spin nonetheless?
02:47karolherbst: allthough, that's maxwell
02:47imirkin: i can't see it
02:47karolherbst: the locked down i2c is pascal+
02:47karolherbst: mhh, should be able to read it there
02:47imirkin: temp is 55C, so not crazy
02:48karolherbst: imirkin: https://gist.github.com/karolherbst/1018d2d068abc2ff1449011f6ad1fff3
02:49imirkin: sure looks similar
02:50karolherbst: I pinged skeggsb about it in mid august
02:51karolherbst: mhh, didn't see it recently so I guess he fixed it on master, but don't really find the fix
02:52imirkin: i do seem to remember this
02:52imirkin: it was something super-non-obvious
02:52karolherbst: imirkin: anyway, with my patches calling abort() when we get notiifed about a dead channel, the entire situation with X gets significantly more stable and less freezy. At least with the GPU faults I was able to trigger
02:53karolherbst: soo, now wondering if we could really just allocated a new channel and move on
02:53karolherbst: that might be interesting
09:52icarious: Hi. Can anyone suggest me a latest (still available in the market) card supported by Nouveau before the Maxwell ones?
09:53icarious: Geforce GT 730 is still available here. I wonder if there are any newer and better cards
13:51RSpliet: icarious: Anything that features a first gen Maxwell is fine, but they're all low/mid-range. For high end, One of those Kepler-based 780Ti or Titan Black will give you the best perf with nouveau
13:52RSpliet: NVIDIA didn't really release desktop 1st gen Maxwell cards... most of them were mobile.
14:19Riastradh: The nouveau header files appear to have had `SPDX-License-Identifier: GPL-2.0' put on them. Can they be adjusted to say MIT or GPL-2.0 OR MIT?
14:20Riastradh: (and some of the .c files)
14:23RSpliet: Riastradh: which part of nouveau are you talking about?
14:24RSpliet: Citing our wiki: "Nouveau is made of 3 components: DDX (2D driver), DRI (3D driver) and DRM (kernel component). The DDX and DRI use the MIT license, the DRM uses a dual MIT/GPL license. REnouveau is under GPL."
14:24Riastradh: kernel component
14:24Riastradh: nouveau/dispnv04/cursor.c:// SPDX-License-Identifier: GPL-2.0
14:24Riastradh: nouveau/dispnv04/disp.h:/* SPDX-License-Identifier: GPL-2.0 */
14:24Riastradh: nouveau/include/nvif/cl0002.h:/* SPDX-License-Identifier: GPL-2.0 */
14:24Riastradh: (I'm not asking to relicense -- I'm just asking to make the tags match the licence that I understood was the intent for the kernel code.)
14:26RSpliet: Ok. I guess the SPDX identifier isn't wrong, but it's also not complete from the sound of it. Thanks for bringing it up. Patches welcome of course, but alternatively mind sending your findings off to the mailing list?
14:26Riastradh: I assume what happened is that someone ran a script over the whole thing to check for copying notices, and defaulted to GPL-2.0 where there is none.
14:26Riastradh: Sure, which one?
14:42RSpliet: Riastradh: nouveau at lists dot freedesktop blahblah would do. Alternatively, you could file a bug on the freedesktop bugtracker. That'll make it easier to track your issue :-)
14:43RSpliet: And I suspect that's exactly what happened. Appreciate your sharp eye!
14:57Riastradh: RSpliet: Product DRI, Component...there appears to be DRM/AMDgpu, DRM/Intel, DRM/Radeon, &c., but no DRM/Nouveau. Wrong product, or should I use DRM/other?
15:07RSpliet: Riastradh: Bugs in the 2D driver and the Nouveau DRM (kernel) part are filed under product “xorg”, component “Driver/nouveau”.
15:12karolherbst: Riastradh: those license identifiers are wrong
15:12karolherbst: and never rely on them
15:12karolherbst: as they are not relible
15:13karolherbst: RSpliet: those are wrong
15:13karolherbst: just assume they are wrong as in most cases they are
15:13karolherbst: (but so are all the other license headers)
15:15Riastradh: karolherbst: I'm currently operating under the assumption that they are wrong and that everything under drivers/gpu/drm/nouveau/ is MIT-licensed, but some official clarification would be appreciated.
15:15karolherbst: greg wrote that patch
15:15karolherbst: and a lot of devs already complained it was pure bs
15:16karolherbst: I have no will to fight it
15:16RSpliet: Riastradh: thanks for the report
15:16karolherbst: all the license headers inside files are worthless in court anyway
15:16karolherbst: they give you a hint what the real license might be
15:16karolherbst: but they aren't always correct
15:16karolherbst: and in doubt you have to follow where each line comes from and figure out under which license they probably were published
15:17karolherbst: which in most cases is the project license (per convention)
15:17karolherbst: Riastradh: there is the weird situation with the linux kernel though, that if you get the linux kernel source, the source files are by default GPL anyway as the kernel is only possible to release under GPL2
15:18Riastradh: My working assumption is that, unless marked otherwise, files under drivers/gpu/drm/ and include/drm/ are xorg-licensed.
15:18karolherbst: you can of course say for non derivate work, that it isn't, which DRM is more or less
15:18RSpliet: karolherbst: why is this a fight? If everyone tries to keep their turf clean it'll be sorted in no time. Nouveau kernel is officially declared as GPL/MIT dual-licensed, so it shouldn't take more than one nasty large patch to resolve the issue, and a little discipline moving forward.
15:19karolherbst: RSpliet: are you sure we were even legally allowed to license it under MIT as it is no derived work from the linux kernel?
15:19karolherbst: who decided that drm is allowed to be licensed under MIT?
15:19RSpliet: Not my problem. This is the decision and we should represent that until it's challenged
15:19karolherbst: RSpliet: sure, but what is legally valid is a different question in the end
15:20karolherbst: RSpliet: it is your problem
15:20RSpliet: You're trying to make this my problem. I don't like others making problems for me...
15:20karolherbst: if you published patches under MIT, then it is
15:20karolherbst: all this IP stuff is pure bs anyway, but that's the situation
15:21karolherbst: if some kernel devs runs amok and sues all devs publishing non GPL patches based on the kernel and some judge agrees with it...
15:21karolherbst: but usually company lawyers backed all this up, so it is kind of safe to assume it is correct
15:21karolherbst: that we license under MIT
15:22karolherbst: anyway, my point is, just because you labeled it with a license, doesn't make it legally correct to use that license
15:22RSpliet: Yes. 100% true. But that's a different problem.
15:25RSpliet: Riastradh asks us to accurately reflect *our* current position in the source files we publish. And our current position is GPL2/MIT dual-licensed, as it's been for as long as the nouveau project has been around afaik. Nobody challenges our position, we're just being asked to be consistent so that others feel less nervous relying on the terms of the license.
15:25karolherbst: RSpliet: I already left a comment, others are free to copy that ;)
15:25RSpliet: Thanks ;-)
15:26karolherbst: I think etnaviv is GPL 2.0 only...
15:26karolherbst: and some other ARM drivers?
15:26karolherbst: Riastradh: you have to be super careful about those GPU drivers for ARM based GPUs as I think all those could be actually be GPL 2.0 only
15:27Riastradh: karolherbst: Yes. I'm in the process of expunging them.
15:28Riastradh: They're all clearly marked as GPL 2.0 -- not by SPDX-License-Identifier headers, but by the text of the licence, consistently across entire subdirectories.
15:28karolherbst: mhh, okay, don't copy my sentences as it should have been "agree with converting them to"
15:28karolherbst: Riastradh: yeah, I think this was intentional though
15:28karolherbst: and they would need to relicense
15:28Riastradh: I'm cutting out: arc arm armada atmel-hlcdc bochs bridge cirrus etnativ exynos fsl-dcu gma500 hisilicon imx mediatek meson ...
15:29Riastradh: We might use those as loadable kernel modules some day, but not statically linked into NetBSD.
15:29karolherbst: what about freedreno? but this might be actually MIT
15:29karolherbst: robclark: ?
15:30karolherbst: yeah, I think so
15:30Riastradh: Looks very clearly GPL-only at first glance.
15:30karolherbst: but okay I guess
15:30karolherbst: mhh, normally the manufacturers provide open source kernel bits
15:30karolherbst: and they license that under GPL 2.0 cause android
15:32robclark: karolherbst, drm/msm is gpl.. mostly because it didn't occur to me to do otherwise.. but tbh, there is quite a lot of other platform drivers needed for gpu to work (iommu, clocks, gdsc (power domains)), etc.. and same is true to varying degrees for the other mobile drivers like etnaviv..
15:33karolherbst: mhh, true
15:33robclark: so getting the arm drivers to work on *bsd seems like a fairly serious effort
15:33AndrewR: imirkin, thanks for all your work on nouveau (nv50) - now I have OpenGL 3.3 for both core and compat = wine runs some Opengl 3.3 tests out of the box (but not dx10 one yet) .....
15:34RSpliet: robclark: is drm/msm the 3D engine, or does it include some chunks of display as well?
15:34robclark: although it is somewhat modular internally.. but both gpu and display re-use the gem code
15:35robclark: (there is some work ongoing to let it work in gpu-only mode on imx5.. as well as corresponding a2xx gpu bits)
15:37RSpliet: What? Is that the Freescale/NXP i.MX5?
15:37robclark: it as what is basically adreno 205
15:37robclark: (prior to it being renamed to 'adreno')
15:38RSpliet: Scandalous... :-P I never knew Qualcomm licensed their GPU design to third parties
15:38RSpliet: (well... they're still a third party right?)
15:38robclark: they didn't, it was amd before qcom bought the ip
15:39robclark: and yeah, prince of orange torpedoed the imx acquisition so they are still a 3rd party
15:39RSpliet: "an anagram of Radeon"
15:39RSpliet: Mind == blown
15:39robclark: heheh, you didn't notice that before?
15:40RSpliet: robclark: I think the Dutch are quite grateful for that. No doubt it would have killed that little bit of CompArch that was still taking place in the country.
15:40RSpliet: (despite NXP being in the hands of foreign investors mostly...)
15:41robclark: personally I was looking forward to qcom SoCs with nxp docs.. since qcom's SoCs are pretty good, but docs not so much so
15:41karolherbst: AndrewR: I guess dx10 on those nv50 devices might be too much in the end. You really want to have a vulkan driver for those
15:42RSpliet: Yeah... I don't think SoC vendors aiming for the consumer market have the time or budget to produce decent docs.
15:42karolherbst: AndrewR: but I doubt we can do vulkan pre kepler...
15:44AndrewR: karolherbst, may be someday I will install some ...geforce 710 (but this specific card might be damaged by statics). Thanks anyway for you too, for making all this possible (I patched kernel so it reclocks card a bit ...not mem, ust core and shader)
15:44AndrewR: karolherbst, https://www.youtube.com/watch?v=pzQROgfc5tQ&feature=youtu.be
15:45orbea: karolherbst: i recall reading a while ago that it was hypothetically (?) possible to do vulkan on much older cards than kepler, am I misremembering or did this turn out to be wrong?
15:45orbea: just curious...
15:59karolherbst: nvidia enabled it on fermi once
15:59karolherbst: but it was broken
17:30imirkin: AndrewR: not just my work. but glad things are working OK. not sure why you wouldn't have DX10 -- those GPUs expose pretty much the full set of functionality.
17:30imirkin: Riastradh: with the license stuff - dunno how it happened - but i think all that code needs to be marked BSD. skeggsb -- are you planning on handling this?
17:31karolherbst: imirkin: I think wine requires higher GL levels for dx10
17:31karolherbst: imirkin: greg wrote a patch to add it to any file missing license headers
17:31imirkin: ok, well, it's wrong.
17:32karolherbst: yeah, a lot of devs complained :)
17:32imirkin: but skeggsb is the author of all those files.
17:51karolherbst: without exceptions?
17:52karolherbst: mhh "nvkm/subdev/iccsense/priv.h" is written by mupuf and me
17:54imirkin: mostly without exceptions ;)
17:54imirkin: anyways - for patches i'm the author of - feel free to license under BSD.
18:01karolherbst: imirkin: well, the issue is not that we have to relicense those files
18:02imirkin: i know.
18:10karolherbst: mhh "../src/mesa/state_tracker/st_atom_framebuffer.c:62: update_framebuffer_size: Assertion `surface' failed."
18:12rhyskidd: karolherbst: if you get a moment, can you review this PR and I'll merge?: https://github.com/envytools/envytools/pull/165
18:13karolherbst: imirkin: nice... that context reset stuff works with chromium
18:13karolherbst: so if it looses a context, it just recreates a new one without falling back to sw rendering
18:14karolherbst: mhh, now it did
18:18karolherbst: seems like it falls back after three tries
18:19karolherbst: imirkin: just got that nouveau_vma_del thing, so I guess it isn't fixed
18:34karolherbst: thing is, chromium is annoying to debug and I doubt it actually uses those robustness things
18:34karolherbst: but the GPU process crashes
18:34karolherbst: so one tab goes boom
18:34karolherbst: but everything else stays
18:38karolherbst: tomorrow I will test that stuff on my other machine with nvidia being main + modesetting ddx + plasma.
18:46karolherbst: I am not quite sure if we can do this on fermi or ealier chips though... probably needs more work on the kernel side
19:23RSpliet: imirkin: you sure about BSD license? My source (GPL/MIT dual) is https://nouveau.freedesktop.org/wiki/FAQ/#index27h3 - the last q. on the FAQ
19:31imirkin: er, yeah, MIT, of course
19:32imirkin: those are equal in my head
19:45karolherbst: well, both are more or less equal anyway
19:48karolherbst: Riastradh: I found some mentioning of the BSD licenses not allowing sublicensing, do you know more about it? Seems like the biggest difference in BSD vs MIT
19:50Riastradh: karolherbst: Can you be more specific?
19:50karolherbst: which I think basically means that if you are not the author you aren't allowed to license BSD work under a different license
19:50Riastradh: The main issue with the historic BSD licence is the advertising clause, which ~everyone has rescinded.
19:51karolherbst: I didn't find very convincing arguments that's the case
19:51Riastradh: Yeah, I've never heard of that. Maybe that's some proprietary variation on the BSD licences?
19:51karolherbst: uhm, no, the issue is more that it isn't explicitly allowed
19:52karolherbst: so you can publish code as GPL+BSD as long as all BSD code stays BSD
19:52karolherbst: and isn't converted into GPL
19:52Riastradh: I dunno, in the decades that the BSD licence has been around it seems like that would have come up more prominently if it were an issue. E.g., the FSF probably wouldn't endorse the <4-clause BSD licences if that were the case.
19:52karolherbst: no, because it isn't really an issue
19:52karolherbst: as license compatibility is something different than what you license your work under
19:53karolherbst: I mean, for GPL we kind of have the same situation, right?
19:53karolherbst: GPL code stays GPL
19:53Riastradh: The FSF probably wouldn't endorse it as GPL-compatible, then.
19:54Riastradh: Of course if it is X-licensed, and you release a modified version that is X&Y-licensed, the original release is still available as X-licensed.
19:54karolherbst: Riastradh: "You can do pretty much what you want with BSD licensed code as long as you keep the original license text in the source code and recognize the original copyright in your (possibly closed source) product."
19:54karolherbst: better worded what I said
19:55Riastradh: Sure. Everyone requires keeping the original licence text. The latter part is the advertising clause.
19:55karolherbst: MIT doesn't
19:55karolherbst: MIT explicitly allows to sublicense
19:55karolherbst: so you can convert MIT code to GPL if you want to
19:55Riastradh: `The above copyright notice and this permission notice shall be included in all copies or substantial portions of the software.'
19:56Riastradh: Assuming you mean <https://directory.fsf.org/wiki/License:X11> by `MIT licence'.
19:56karolherbst: I think
19:56karolherbst: but it allows sublicensing though
19:56Riastradh: The copyright holder can always change the licence altogether.
19:56karolherbst: that's true
19:57mupuf:always assumed the entire nouveau codebase was MIT
19:57Riastradh: Derived works can always add more conditions that are not incompatible with the original licence, so I can take a BSD-licensed thing and add the restriction that my derivative never be published in green ink.
19:57karolherbst: mupuf: it is. somebody just put wrong licensing information
19:57Riastradh: But that doesn't change the licence on the _original_ that I derived my work from.
19:57mupuf: karolherbst: I hope it is not me :o
19:57karolherbst: sure, the original stays MIT
19:58Riastradh: mupuf: Yes, I'm just concerned about the automated addition of SPLX-License-Identifier headers: https://bugs.freedesktop.org/show_bug.cgi?id=107874
19:58karolherbst: mupuf: it is greg
19:58karolherbst: he went berserk and added a GPL tag to all files without license headers
19:58karolherbst: you can imagine how controverse that was after people found out ;)
19:59mupuf: no shit sherlock, yeah
19:59mupuf: ttyl though!
19:59mupuf: but I'm not far and I definitely support the re-licensing when everyone agrees
20:00karolherbst: we don't change the license ;)
20:00karolherbst: and nobody has to agree
20:00karolherbst: stuff is MIT, period
20:00karolherbst: well, I hope that it is :D
20:01karolherbst: patches on a ML are always kind of difficult to know which license the author thought he would publish the changes udner
20:01karolherbst: tricky situation
20:01karolherbst: especially as the kernel as one thing is GPL
20:02karolherbst: Riastradh: I guess I would have to lookup what "sublicense" actually means, but maybe that's a contradiction inside the license
20:02karolherbst: I was mainly wondering if you knew more
20:04RSpliet: karolherbst: the license is clearly stated on the nouveau wiki. I'd say authors who care but didn't look into the issue have neglected their responsibility.
20:04karolherbst: RSpliet: nope
20:05karolherbst: RSpliet: normally you have to ask the person before merging the patches, because you can't expect that
20:05karolherbst: and there is no disclamer stating: "by posting patches on this Mailing list, you agree to license all patches under the MIT license", _before_ being able to post patches
20:05RSpliet: That's clearly what every gatekeeper of every OSS project does...If you offer changes to a project, you do that on the project's terms.
20:06karolherbst: this is about law/legal stuff, not common sense ;)
20:06karolherbst: you _might_ be able to reasons that's the way things are done in general
20:06karolherbst: and people _might_ agree to your reasoning
20:06karolherbst: normally companies which own code, usually require you to agree before hand
20:06Riastradh: karolherbst: I think it's understood to be implied by `redistribution and use...with or without modification, are permitted provided that the following conditions are met'.
20:06Riastradh: You can always add more conditions to redistribution and use; you just can't violate or remove those conditions.
20:07Riastradh: Can always add more conditions to redistribution and use of derivatives, that is.
20:07karolherbst: yeah, maybe that's the case
20:08karolherbst: so you can basically remove the MIT license as long as the new license contains the words stated in the MIT license? Dunno for sure. All those details are fuzzy
20:08RSpliet: This is 100% about common sense. Law only comes into play when people start defying and questioning common sense, because that's when an independent party (a judge) gets to decide.
20:09Riastradh: Well, you can't remove the copyright notice, so.
20:09karolherbst: Riastradh: yeah...
20:09karolherbst: Riastradh: that's why I am wondering about that sublicense term
20:09karolherbst: so maybe it makes a difference compared to BSD
20:09karolherbst: maybe it does not
20:10Riastradh: Cursory web search suggests it matters only for redistributions of _identically the same_ work.
20:10karolherbst: RSpliet: well, but that stuff happens from time to time, that some kernel devs are just sueing people for bs reasons
20:10rhyskidd: karolherbst: a point re: asking developers before their code is merged. code that was "Signed-off-by:" per the Developer Certificate of Origin means they understand and acquiesce to the open source license
20:10karolherbst: Riastradh: I disagree
20:10karolherbst: Riastradh: or wait...
20:11karolherbst: no, BSD states that stuff
20:11karolherbst: MIT doesn't
20:11Riastradh: If by `MIT' you mean <https://directory.fsf.org/wiki/License:X11>, it does require that you keep the notice.
20:11karolherbst: no, I meant the _identical_ part
20:12karolherbst: MIT: "notice shall be included in allcopies or substantial portions of the Software"
20:12karolherbst: which is different than _identical_
20:12rhyskidd: a technical question re: implementing new functionality in demmt
20:12rhyskidd: see: https://gist.github.com/Echelon9/c10d392a05506bd0af74e7bd33d6b0de
20:12rhyskidd: i'm trying to trace the one ioctl "/dev/nvidia-modeset" provides
20:13karolherbst: rhyskidd: what if somebody didn't read it and did the "Signed-off-by" thing because everydboy else was doing it ;)
20:13Riastradh: karolherbst: Sorry, what I meant is that it seems the explicit `sublicense' permission that is explicitly stated in the MIT/X11 licence makes a difference from the BSD licence only in identical copies of the work.
20:13karolherbst: if you want to be sure, you really really want to have something everybody has to see before that person code is able to be merged or seen
20:13rhyskidd: i'm having trouble where the data doesn't actually end up being (ioctl->size == buf->len)
20:13Riastradh: (at least, that's the only difference I've heard of now)
20:14karolherbst: rhyskidd: mhhh
20:14rhyskidd: logs are in the gist
20:14karolherbst: rhyskidd: it might be that we have the same problem there as with the nvidia-uvm things
20:14karolherbst: rhyskidd: where nvidia doesn't follow ioctl structure rules
20:14karolherbst: check nvidias source code
20:14karolherbst: maybe they have the ioctls listed for modeset as well
20:14karolherbst: for uvm they do ;)
20:15rhyskidd: ok, so we have knowledge that nvidia may not follow the ioctl structure rules
20:15karolherbst: check my patches for uvm
20:15rhyskidd: and that might be why i see the "size" field as 16 but the data.len is 0
20:15karolherbst: there you see how I handled all that stuff
20:16rhyskidd: ok, that's helpful. i was worried some of the data might be getting dropped on the floor somewhere between valgrind-mmt and demmt
20:16karolherbst: rhyskidd: for uvm I basically set the size to sizeof(struct nvuvm_whatever_ioctl)
20:16karolherbst: rhyskidd: https://github.com/karolherbst/valgrind/commit/e29d6ef2b3de297f20c7f52756f3de50ad9461ba
20:16karolherbst: check mmt/nvuvm_ioctl.h
20:20karolherbst: RSpliet: once I relicensed some patches under CC0, because one company was forcing devs to relicense + signing a CLA to grant authorship rights to that company. So apperantly a stupid comment from me on the github bug tracker stating that wasn't enough. They actually wanted that I sign something with address and legal name and everything.
20:20karolherbst: all that stuff is super annoying
20:20karolherbst: just depends on how paranoid you or your lawyers are
20:21karolherbst: today some projects use that github CLA agent stuff where contributors agree that they license their work under the license stated inside the project ;)
20:22karolherbst: and the CLA text is basically: "you keep all your rights, you permit that your stuff is shared under license X, pls sign here"
20:23mslusarz: rhyskidd: you need to add ioctl-class specific code to mmt
20:23karolherbst: khronos is doing it for example
20:23rhyskidd: mslusarz: yep, ok understood
21:06rhyskidd: what is this empty envytools repo used for? https://github.com/envytools/scans
21:11karolherbst: imirkin: interesting, "dEQP-EGL.info.vendor" fails with ../src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c:158: nouveau_drm_screen_create: Assertion `reserved_addr' failed.
21:11karolherbst: ohh wait
21:11karolherbst: local stuff