01:44feliksk: how do you check the version of nouveau? or is it tied in with the kernel version that you have
01:46imirkin: feliksk: there are different portions of it
01:46imirkin: some in kernel, some in mesa, some in an xorg ddx
01:47feliksk: yeah, im looking to check the version in the kernel part
01:47feliksk: for now
01:49feliksk: i have a gt 440 card and the fan is really loud
01:49feliksk: not using X right now, just the text console
01:50feliksk: when i run the kernel with 'nomodeset' the fan is quiet again
01:52imirkin: mupuf: --^
01:52imirkin: we have issues controlling the fan for some of the gpu's
01:52feliksk: well im not sure yet
01:52feliksk: i think slackware 14.1 didnt have my fan spinning loud
01:52feliksk: when i changed to slackware 14.2 i think the fan started going loud
01:52imirkin: and in other cases, we can control it just fine, and then go right ahead and mess it up anyways
01:53feliksk: im installing 14.1 to see if the fan is normal there
02:00feliksk: just installed 14.1 and the fan is quiet
02:00feliksk: something happened between slack 14.1 and 14.2 in nouveau that caused the fan to go loud on my graphics card
02:00imirkin: ok, well we don't support distro versions
02:00imirkin: that doesn't mean it's not useful information
02:00feliksk: do you want to know the kernel versions that i have in 14.1 and 14.2?
02:00imirkin: what kernels are used by 14.1 and 14.2
02:01feliksk: i am running 14.1 at the moment and uname -a says im using 3.10.17-smp
02:01feliksk: when i was running 14.2, it said 4.4.19-smp
02:01imirkin: wow. that's like ... at least 2 rewrites in between
02:01imirkin: probably more like 3
02:01feliksk: are there nouveau versions?
02:01feliksk: i can try going in between
02:01imirkin: each kernel is a version.
02:01feliksk: and seeing what version broke the fan control for my card
02:01feliksk: is a nouveau version tied to a kernel version?
02:02imirkin: you just jumped 14 versions.
02:02imirkin: and something went wrong somewhere in there
02:02feliksk: i am confused how this version thing works, so it's completely connected with the kernel?
02:03imirkin: actually i think back in 3.10 we didn't enable auto control of the fans at all
02:03imirkin: there is no such thing as "nouveau"
02:03imirkin: there is "the nouveau kernel module"
02:03imirkin: which is part of the kernel
02:03imirkin: and controls things including but not limited to fans
02:03feliksk: yeah im talking about the kernel module
02:03feliksk: not using X at all right now
02:04imirkin: changes to nouveau go into (almost) every kernel version
02:04feliksk: so could i disable the fan control in the 4.4.19? ill probably just run on nomodeset for now, X still works just at a low resolution
02:06feliksk: actually jk, i dont want nomodeset :P
02:06feliksk: kinda sad how going up a version makes the fans go really loud
02:07imirkin: you mean skipping ahead 14 versions
02:07feliksk: yeah, i could try going in between versions and seeing when it starts happening
02:08feliksk: or just switch off fan control (cause you said it probably wasn't even in 3.10) in 4.4.19
02:08feliksk: would i need to recompile the kernel or something insane to do that?
02:14feliksk: ok, do you know how i could switch off the fan control
02:25feliksk: ok well i guess im gonna have to do more work instead of just being annoying in the irc
02:25feliksk: ill try switching kernel versions, expect to see me later :P
02:26imirkin: you can control the fan manually
02:26imirkin: there is various documentation available for this
02:27feliksk: so you think that in 3.10 the fan wasn't controlled at all?
02:28feliksk: ill check out that page, thanks
02:31imirkin: i think that in 3.10 we didn't mess with fan controls by default
03:09s0be: pstate/reclocking seems to work for me. Neat.
03:10s0be: so I have a GM107, is there any interesting testing people might want?
03:20imirkin: things are pretty much expected to work...
03:20imirkin: hakzsam is working on a sched calculator for maxwell, but that's not ready yet
03:27s0be: cool, I don't every do anything requiring up-clocking (and rarely even need to power up the discrete gpu), but figured I'd offer
05:35mupuf: gnurou: ok, let's try a new kernel on the tk1
05:35mupuf: I'm building a 4.8
06:11gnurou: mupuf: should fly!
06:36mupuf: gnurou: good, except I screwed up in the .config, apparently
06:36mupuf: it boots but no network
06:37mupuf: the serial console is fine, but I have only a few modules
06:37mupuf: that's all I can do remotely
06:37mupuf: will make it work this week end :)
06:37mupuf: nouveau loads properly, so all is well ;)
06:43mupuf: hakzsam: maybe your patch to enable ARB_enhance_layouts should land
06:44mupuf: but we should probably refrain from exposing 4.4+ though
06:44mupuf: we need to get in touch with Khronos
06:45mupuf: and ask them if they accept sending us the CTS for free
06:46mupuf: otherwise, we will have to change the OpenGL version string to say we are uncompliant
06:47mupuf:needs to ping idr again to see what is the status of this discussion
07:07karolherbst: mupuf: uhh, with 4.4+ we need to be "officially compliant"?
07:08karolherbst: ohh conformance tests landed with the 4.4 spec.. I see
07:21gnurou: mupuf: maybe the firmware for USB (nvidia/tegra124/xusb.bin) is missing - check your boot logs. I think the network device is on the USB bus, which would explain why it doesn't show up
07:49mupuf: oh, can be!
08:00karolherbst: uhh by the way, does anybody know how I can get bootlogs of android devices while having _no_ adb running yet? doesn't matter if I have to check the fs, I can do this. I just messed up an old device of mine
08:09hakzsam_: mupuf, or we just don't care, and push
08:11hakzsam_: I REALLY doubt Khronos will send us CTS for free :)
08:12hakzsam_: and yeah, I will push my for ARB_enhanced_layouts today
08:12hakzsam_: yeah, cheap! :p
08:13mupuf: You may not use any wording that implies that your implementation is "compliant" or “conformant” or fully implements the specification
08:13mupuf: You cannot use the name of the API or its logo in association with your implementation in any way
08:14mupuf: so... if you want to push it, you need to rename the gl string to MesaGL or something like this
08:16hakzsam_: what happens if we say "we are compliant" without validating the CTS stuff? :)
08:16mupuf: law suite
08:16mupuf: on your name or mesa as a whole
08:16mupuf: yes, this is trademark dude
08:17hakzsam_: international lawsuit? :)
08:17mupuf: well, I am sure they could find ways
08:17hakzsam_: maybe, they are gentlemen and send a C&D before?
08:18mupuf: they likely would, but we did not even send an email to them
08:18mupuf: so... until we fix this thing, how about we rename OpenGL to MesaGL
08:18mupuf: this way, we distance ourselves from Khronos
08:18mupuf: and we are good
08:18mupuf: can you give the output of glxinfo?
08:18mupuf: let's check this
08:18hakzsam_: is that not a lie?
08:19hakzsam_: nope, I really need to go to work actually :)
08:20Manoa: I have no problem with this, nobody have money for CTS and whay need compliant anyway ? it's for play games afther all - THAT is a complience of itself XD
08:20hakzsam_: mupuf, okay, I won't push the GL 4.5 enable patch
08:21hakzsam_: I mean, without changing ot MesaGL
08:21hakzsam_: or something like that
08:22karolherbst: what a mess....
08:30mupuf: karolherbst: can you send me the output of glxinfo on your card?
08:30mupuf:does not run nouveau on his desktop machines as I am dogfooding for intel
08:32karolherbst: I am currently at work :p
08:32mupuf: ack! Reator is running, will get it from there ;)
08:35karolherbst: well, doesn't have mesa the same issue in general anyway?
08:36karolherbst: what if a software driver gets to 4.4?
08:37mupuf: same problem for the sw drivers
08:37mupuf: and it is also for GLES 3.1 IIRC
08:37mupuf: need to check
08:37mupuf: Intel and AMD are paying for this
08:38mupuf: we don't
08:39karolherbst: yeah, I am aware
09:03mupuf: OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.0 --> MesaGL 4.5 (Core Profile) Mesa XXXXXXXX
09:04mupuf: OpenGL ES profile version string: MesaGL ES 3.1 Mesa 11.2.0
09:04mupuf: OpenGL ES profile shading language version string: MesaGL ES GLSL ES 3.00
09:04mupuf: it may break some scripts ... but whatever?
09:04hakzsam_: it may
09:05karolherbst: mupuf: well, basically we don't return "OpenGL" inside any string, are we?
09:05karolherbst: ohh "OpenGL ES"
09:05karolherbst: and for the desktop gl?
09:05mupuf: we don't, but we do not distance ourselves from Khronos either
09:06karolherbst: I see
09:06hakzsam_: MesaGL is good
09:06mupuf: yeah, I like the name too.
09:06karolherbst: should be discussed on the ML before maye
09:06karolherbst: not that somebody is really against it or whatever
09:06mupuf: karolherbst: of course
09:07karolherbst: but yeah, I am also fine with MesaGL
09:07mupuf: or we add (uncompliant) or (uncertified)
09:08mupuf: then we will send an email to Khronos to ask them what steps we should take
09:08mupuf: but this will be part of a larger discussion
09:09hakzsam_: in any cases, I think I will need to add a new cap like PIPE_CAP_CTS or something
09:09mupuf: oh, nice idea
09:10mupuf: and if it is OpenGL ES 3.1+ or GL 4.4+, you add (non-compliant)
09:10hakzsam_: yep, that's the idea
09:10mupuf: this actually would be better than MesaGL
09:10mupuf: You may not use any wording that implies that your implementation is "compliant" or “conformant” or fully implements the specification --> We would make sure to advertise it is not compliant
09:10mupuf: and the cap can be made per generation
09:10mupuf: which is perfect
09:11mupuf: great idea Samuel!
09:11mupuf: let's send it quickly so we can advertise 4.5 in the next mesa version
09:12hakzsam_: yeah, will look how I can do that
09:12mupuf: well, the second point is still problematic though, for OpenGL ES
09:12mupuf: "You cannot use the name of the API or its logo in association with your implementation in any way"
09:13hakzsam_: well, don't expose ES 3.2 for now and should be good :)
09:14mupuf: 3.1 is also covered IIRC
09:16karolherbst: mupuf: you know in detal when you are able to use the name OpenGL for 4.4+ ? It may be, that simply adding "non-compliant" won't cut it
09:18karolherbst: well, they can't prevent us from reimplementing their API
09:18karolherbst: we could even expose 6.0 as the version string, cause it doesn't matter
09:19karolherbst: trade mark isn't about silly strings we produce in the binaries, but more if we use their trademarks for other things
09:19karolherbst: or nit directly
09:19karolherbst: if we would export their logo => problem
09:19mupuf: the name is apparently enough
09:19karolherbst: maybe even claiming we are an "openGL" implementation
09:20karolherbst: that might be too far
09:20karolherbst: but if our library doesn't produce the name as any API output we are fine
09:20mupuf: not if we say non-compliant OpenGL implementation
09:20mupuf: so, as long as we make it clear, I think it is fine
09:20karolherbst: that was my point regarding claiming "non compliant opengl"
09:20karolherbst: we could export "4.5 non-compliant" maybe
09:21mupuf: for gles 3.1+ and gl 4.4+, we just add (non-compliant)
09:21karolherbst: and just drop "OpenGL" as a string completly
09:21mupuf: OpenGL is nowhere to be seen
09:21karolherbst: well yeah, but we shouldn't use "OpenGL" in any way to be safe
09:21karolherbst: it is
09:21karolherbst: for OpenGL ES
09:21mupuf: only OpenGL ES is
09:21mupuf: right :D
09:21mupuf: in this case, this could be renamed MesaGL
09:22karolherbst: maybe error output might be tricky as well
09:22karolherbst: no idea where we actually use the string "OpenGL"
09:22mupuf: but let's not push it
09:22mupuf: I am sure they will be fine with this
09:22mupuf: we explicitely say that we are not compliant
09:22mupuf: in the version string
09:22mupuf: the rest can wait
09:23mupuf: the xorg board will talk to them
09:23karolherbst: well, oracle+google had a lot of fun with stuff like this in the past :D I am sure khronos won't do the same
09:23ystreet00: glGetString(GL_VERSION) requires "OpenGL" in the string
09:23karolherbst: ystreet00: "non conforment" for a reason ;)
09:23karolherbst: or compliant or whjatever
09:23karolherbst: if we don't claim to be compliant we can export whatever we like
09:23ystreet00: and would break applications that depend on that
09:23karolherbst: that's the trick
09:23mupuf: ystreet00: that's a funny thing because we do not export this already :s
09:24mupuf: ystreet00: http://pastebin.com/9bhGYKJP
09:24ystreet00: for ES you do
09:24mupuf: ah, right
09:24mupuf: then I guess (non-complient will do the trick)
09:24mupuf: let's see the spec
09:25ystreet00: e.g. https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglcontext.c#n537
09:25karolherbst: maybe 0p3ng1 is fine too
09:26mupuf: The GL_VERSION and GL_SHADING_LANGUAGE_VERSION strings begin with a version number. The version number uses one of these forms:
09:26mupuf: this is what the GLES 3.2 spec says
09:28mupuf: so mesa is doing the wrong thing
09:28karolherbst: mupuf: so OpenGL ES is wrong anyway?
09:28karolherbst: nice :D
09:28ystreet00: the man pages conflict with the spec
09:28mupuf: yeah :D
09:29mupuf: ystreet00: this is the spec...
09:29ystreet00: and are probably copied from non-ES GL
09:29karolherbst: ystreet00: then tell us where in the spec we should look at
09:29mupuf: oh, he is right
09:29ystreet00: GLES 3.1 spec 19.2
09:29ystreet00: page 353
09:30mupuf: well, here we go
09:30ystreet00: not the first time ;)
09:30mupuf: ystreet00: thx!
09:30ystreet00:doesn't trust the man pages anymore
09:31mupuf: well, here we go
09:31mupuf: "(non-complient)" will have to do
09:31mupuf: because Khronos says we are free to implement the spec
09:31karolherbst: well doesn't matter what khronos say anyway
09:31karolherbst: we are allowed to implement no matter what they say
09:31mupuf: lol, yes it does
09:32karolherbst: no it doesn't
09:32karolherbst: didn't follow the oracly-google java thing?
09:32mupuf: google does not call it Java
09:32karolherbst: and we call it mesagl
09:32mupuf: Java is tradework
09:32mupuf: and so is OpenGL
09:32mupuf: so ...
09:32karolherbst: but API isn't covered by this
09:33mupuf: yes, it shouldn't
09:33karolherbst: it isn't
09:33mupuf: this is ABI, so it is not OK to change
09:33mupuf: well, this is all grey waters, so let's just do our best
09:34karolherbst: well we can't violate trademarks while implementing an API though, that was my comment about not using "OpenGL" at all
09:34mupuf: and adding (non-complient) should make it clear-enough that this is not OpenGL (TM)
09:34karolherbst: but if a function contains "opengl" in it's name it is covered by fair use
09:34mupuf: no function has this
09:34mupuf: and yeah, let's not be stupid about this
09:34karolherbst: it was just an example
09:35karolherbst: maybe even being API compliant might be covered by fair use
09:35mupuf: let's do this and contact Khronos for the case where we want to be compliant
09:35mupuf: no, "compliant" is a stamp that can be given by Khronos alone
09:35karolherbst: allthough I am like 70% sure we could export "OpenGL" in strings if we follow a spec for our implementation though
09:36karolherbst: because it would fall under fair use
09:36mupuf: we can say we follow the spec, but it has not been validated by Khronos so it is not compliant
09:36mupuf: fair-use... lol
09:36mupuf: as long as a judge does not rule that, we are not cleared
09:36mupuf: and I do not want to go and see a judge
09:36mupuf: and spend time and money on this
09:36karolherbst: that was my 70% about
09:37karolherbst: we aren't even commercial, so chances are pretty high
09:37karolherbst: but yeah, I don't want to do that kind of thing
09:38mupuf: so, the plan is: add a cap in Gallium for CTS. If the cap is not present, add "(non-compliant)" right after the version number
09:38mupuf: for GLES 3.1+ and GL 4.4+^
09:40mupuf: I am sure it will break parsers but ... whatever?
09:41mupuf: they should deal with this better
09:41mupuf: and read the spec
09:42karolherbst: we could also just ask khronos if we are allowed to follow the specs 100% even without paying as long as we still don't claim to be compliant allthough yeah no idea
09:42karolherbst: then we don't need those silly hacks
09:46mupuf: whether they accept it or not, it is good to be clear
09:47mupuf: and this cap will allow us to expose versions before we fix all the issues, which is not a bad plan
09:48mupuf: think about the case where an environment variable forces the GL version
11:06hakzsam_: mupuf, how about this http://hastebin.com/abinukolod.pas ?
11:06hakzsam_: this doesn't require to add any caps
11:30mupuf: hakzsam_: I don't like it
11:31mupuf: this field is not supposed to change between versions
11:31mupuf: this is what the spec says
11:31hakzsam_: yeah, but if you want to add "non-compliant" in the OpenGL strings, this will require to change mesa core...
11:32hakzsam_: the thing I did is really easy, and only needs to make changes in nvc0 code source
11:32hakzsam_: not even in gallium
11:32karolherbst: the problem also exists in mesa core
11:32karolherbst: and now you added a "OpenGL"
11:33hakzsam_: like I said, changing mesa core for that is a pain
11:34karolherbst: so? anyway, your change is a bad one as mupuf already said
11:34karolherbst: application do check those
11:35karolherbst: also the idea was to not use "OpenGL" as a string anywhere, so you would end up with " Gallium 0.4 on NVE7 (non-compliant)" in the end
11:38hakzsam_: I don't think application do parse the "OpenGL rendered string", anyways, changing mesa core ONLY for Nouveau is no the right thing to di
11:39mupuf: hakzsam_: software renderers will also need this
11:39mupuf: so it is not only for mesa
11:39mupuf: and yeah, changing mesa core is ... annoying
11:39hakzsam_: they currently do not even expose GL 4.3 ;)
11:40mupuf: it is a question of time ;)
11:40hakzsam_: long time :)
11:41karolherbst: anyway, this will also affect other gallium drivers and I doubt every will take care of this
11:42karolherbst: hakzsam: I guess your change is nouveau only?
11:42mupuf: yes, his change would be super easy
11:42karolherbst: right, so we need this at least within gallium for every driver anyway
11:43hakzsam_: that was my first idea, add a new cap ;)
11:43mupuf: hakzsam_: how about this, add another function that sets up the opengl version name, but for non-certified drivers
11:43mupuf: and let gallium call either ones depending on the cap
11:43karolherbst: silly client, wanted to search
11:43mupuf: the non-certified version will call the certified version if GLES3.1- or GL4.4-
11:44mupuf: and otherwise will construct the right version string
11:44hakzsam_: mupuf, yeah, something like that should work
11:44mupuf: this way, we have the check on the opengl versoin only once in the entire mesa
11:44mupuf: and you don't get to fix all the drivers
11:44mupuf: and distros patching mesa should also force using the non-certified version
11:44karolherbst: but if the new function is for the non certified one, the drivers may miss it
11:45mupuf: karolherbst: drivers need to be aware
11:45mupuf: hakzsam_ will fix the gallium drivers
11:45mupuf: which, IMO, is all we care about
11:46karolherbst: I guess distros won't care much though, cause they usually patch things
11:46mupuf: Intel is the only non-gallium driver wich is still maintainer and developeed
11:46mupuf: karolherbst: their problem
11:46mupuf: not our
11:46karolherbst: but does that mean every release has to be recertified?
11:47karolherbst: or is it enough to run the tests again
11:47mupuf: the current understanding is that you certify it once then you guarantee there no regressions
11:48karolherbst: I see
11:48hakzsam_: and re-checking CTS before a new release is easy to do
11:48hakzsam_: once it worked before :)
11:48karolherbst: and if there is one out in the public, you get a nice mail from khronos saying: pls fix, else certification gone
11:48mupuf: there are no public ones
11:48mupuf: it is only for vulkan that they did it
11:48karolherbst: I meant, regression
11:49karolherbst: it is a little tricky with mesa, cause it is always out and we can't verify that every git commit passes those tests
11:49karolherbst: and we can't even say for every device
11:49mupuf: karolherbst: wait until ezbench does it ;)
11:49karolherbst: but I also don't know how the procedure is
11:50karolherbst: is it on a driver base or per "whatever" string?
11:50hakzsam_: mupuf, talking about this, you will have to plug/unplug a bunch of GPUs this weekend (after the release), I want to check piglit :)
11:50mupuf: the procedure is that you send your CTS results (if you patched CTS, you need to say what you changed), then wait 30 days for complaints
11:50mupuf: hakzsam_: ack
11:51hakzsam_: features freeze should be tomorrow
11:51mupuf:could run CTS for nouveau, but this is not really great :s
11:51hakzsam_: let RH folks do it for us :)
11:51mupuf: yeah, Ben could be more involved on this ... but that is not a priority
11:52hakzsam_: airlied reported us a bunch of fails already
11:52mupuf: in this*
11:52hakzsam_: and nha is going to fix all st/mesa fails
11:52hakzsam_: so it will be in good shape after that
11:52hakzsam_: all the remaining fails will be in nvc0 :)
11:53mupuf: and hopefully, we can get the X.Org foundation to access CTS
11:53mupuf: and share it to its members
11:53hakzsam_: X.Org can pay 10KUSD for CTS?
11:53hakzsam_: that would be very nice though
11:54hakzsam_: anyway, I will try to cook something for GL 4.5 before tomorrow
11:55mupuf: nope, but we could ask to get it for free
11:55mupuf: there are nice words for open source drivers
11:55mupuf: like we may be able to get it for free if we get in touch
11:55mupuf: so we will do
11:55mupuf: but we need a legal entity for this
11:55mupuf: mesa can't be the holder
11:55mupuf: it has to be X.Org
11:56mupuf: that's it
11:58karolherbst: sounds like a plan
12:02karolherbst: but one thing: do we have to run the CTS on one GPU or do we have to be sane about it and run it once for each chipset?
12:02mupuf: each chipset, of course
12:11karolherbst: yeah, just asking
12:11karolherbst: maybe there is a more formal requiernment like each "renderer string" or something like that
12:12mupuf: karolherbst: trust me, hw manufacturers do not need to care, they just pay
12:13Guest81731: hi, I am running gentoo with nouveau driver and GeForce 9500 GT (NV96 chipset)
12:13Guest81731: after starting sddm, I left with black screen and blinking curson in left-bottom corner of the screen
12:15Guest81731: /var/log/messages shows me a lot of errors like:
12:15Guest81731: nouveau 0000:01:00.0: gr: 00000030 [ILLEGAL_MTHD ILLEGAL_CLASS] ch 2 [001fb16000 X] subc 2 class 0000 mthd 08c8 data 00000000
12:15Guest81731: nouveau 0000:01:00.0: fifo: CACHE_ERROR - ch 127 [unknown] subc 3 mthd 0f04 data 00000000
12:15Guest81731: there are hundereds of them
12:16karolherbst: mupuf: :D k
12:36igmp: Hi, I'm new to graphics driver so sorry if t. Is it the role of nouveau to translate
12:37igmp: Hi, I'm new to graphics driver so sorry if my question is dumb. Is it the role of nouveau to "compile" opengl into gpu "assembly"?
12:37karolherbst: it is one part
12:37mupuf: it compiles GLSL code into assembly
12:39igmp: mupuf: and this assembly is GPU dependent, right?
12:46igmp: so all of this compilation is done inside the pipe driver?
12:48igmp: thank you, it's more clear for me now ^^
12:49mupuf: you're welcome
12:51mupuf: imirkin_: you may want to check the logs
12:51mupuf: it is related to the adopters program and exposing 4.4+
12:51mupuf: we came up with somethikng that should be enough for now, until we contact Khronos
13:16imirkin: mupuf: do you distribute an implementation that claims to be OpenGL conformant? i know i don't.
13:17imirkin: ianal, but it could be xorg foundation's problem
13:17mupuf: it is
13:17imirkin: either way, happy to s/Open/Closed/ all over
13:17mupuf: but making it clear it is non-conformant until we get more information from Khronos would be good
13:18imirkin: if you raise the issue with khr, they have to act on it
13:18imirkin: the action will definitely not be in our favor
13:18imirkin: i'd rather leave things alone
13:18imirkin: and get glvnd to rename its lib to libGLloader or something
13:19mupuf: https://www.khronos.org/conformance/adopters/ --> this is pretty clear that we can do it
13:19mupuf: first sentence
13:20imirkin: "that we can do it"? do what?
13:20mupuf: have a GL 4.5 driver
13:20imirkin: well, OpenGL is trademarked (i assume)
13:20imirkin: and you need to use the string OpenGL in order to have an OpenGL impl
13:20imirkin: so ... doubtful.
13:21mupuf: well, this part is part of the spec that we are free to implement
13:21imirkin: yes, we are free to implement it
13:21imirkin: and they are free to sue people
13:21mupuf: and free to get sued :D
13:22imirkin: either way, it's a little unfortunate this has spilled over into irc
13:23mupuf: this would hold only against a judge (plausible deniability of not knowing)
13:24mupuf: but seriously, it is all there, in plain sight, I doubt it would hold
13:24mupuf: and /me does not want anyone to even get this far
13:24karolherbst: imirkin: there is still fair use ;)
13:25mupuf: adding (non-compliant) would definitely obey the spirit of what they are trying to achieve with their trademark enforcement
13:25mupuf: only Adopters may say that they are compliant
13:25mupuf: we just need to make it clear in our communication that we are not compliant, that's it
13:25imirkin: i dunno. if this becomes an issue i'd much rather start a new project, Closed3D or something, and go from there.
13:26karolherbst: they just don't want people making money writing opengl drivers without they getting anything! :D
13:26mupuf: karolherbst: nope, they want to make sure every driver behaves in the same way
13:26imirkin: mupuf: i would avoid taking any action until required.
13:26karolherbst: mupuf: I wasn't serious
13:26karolherbst: nope, I would ask them, because we really want to use their tests
13:27mupuf: karolherbst: this will be the job of the foundation
13:27imirkin: i don't particularly want to use their tests
13:27mupuf: and this will require every mesa dev to agree that the X.Org foundation may represent them
13:27imirkin: why do you?
13:27karolherbst: isn't it obvious?
13:28mupuf: imirkin_: to reduce the number of bugs in our driver / differences with other drivers which are going to create issues with applications
13:28karolherbst: devs care
13:28mupuf: karolherbst: devs are never going to support nouveau
13:28karolherbst: they always complain if driver a behaves different than driver b
13:28karolherbst: not true :D
13:29karolherbst: there are some actually who wants
13:29karolherbst: one XNA guy
13:29RSpliet: now this is funny! I have an OpenCL program that uses $r36, but not $r33-$r35
13:29mupuf: what's that?
13:29RSpliet: in other words, they seem to do some post-RA optimisation but didn't bother with a reg renaming pass
13:30karolherbst: mupuf: linux implementation of FNA
13:30karolherbst: ohh wait
13:30karolherbst: FNA is linux implementaiton of XNA
13:30karolherbst: some microsoft framework for games
13:30karolherbst: used in rogue legacy for example
13:30mupuf: this is not a corporate project
13:30karolherbst: *small games
13:30karolherbst: he is a paid dev
13:30mupuf: ok, that counts then
13:31karolherbst: and yes, it is
13:31karolherbst: basically porting XNA based games to linux is the business
13:31mupuf: OK, my bad then
13:31karolherbst: imirkin: you didn't get any replies from the ML I suppose?
13:31karolherbst: regarding that format thing
13:33karolherbst: the RGB5_A1 issue?
13:33karolherbst: game engine being silly, maybe?
13:33imirkin: not sure i remember what you're talking about
13:33imirkin: sounds mildly familiar
13:33karolherbst: ohhw ait
13:33karolherbst: it was GL_RGBA4
13:33imirkin: oh, the RGBA4444 being renderable
13:33imirkin: nope, no reply
13:34karolherbst: mupuf: anyway, it sounded like if we found a bug inside their engine, which only occurs on nouveau and violates the OpenGL spec, they would rollout new releases
13:34karolherbst: maybe not for all games, but for the compatible ones against the current FNA tree
13:35hakzsam_: imirkin, mupuf to sump up, what's the plan then for GL 4.5?
13:35karolherbst: imirkin: yeah, I guessed. I followed a little :/ it is an important issue though
13:35karolherbst: well "important"
13:35karolherbst: maybe something regarding this is inside the CTS :D
13:35RSpliet: (speaking of no reply, the network infra around my mail server has been playing up, so I don't receive e-mails atm.)
13:36imirkin: hakzsam_: at the very least, push enhanced layouts
13:36hakzsam_: imirkin, sure, I will do later today
13:36imirkin: when radeonsi bumps their version, we should too.
13:36hakzsam_: okay, so no 4.5 for mesa 13?
13:37imirkin: i'd rather go in line with radeonsi
13:37hakzsam_: okay, makes sense
13:37imirkin: nha is tracking down some issues in st/mesa now
13:37hakzsam_: yes, I know
13:46mupuf: well, I checked quickly and found no mention of "compliance"
13:47mupuf: but I would really like to see a strong message on the other direction (stating that we are not, unless the driver overrides this)
13:48mupuf: but I do not think we are in danger. At least, we would get a cease and desist or recommendations from Khronos before them attacking us
13:50RSpliet: think they can send over some engineers to iron out the bugs? :-P
15:06karolherbst: imirkin: any plans for the RGBA4444 situation then?
15:07imirkin_: i'll ping the thread
15:07imirkin_: unfortunately i don't have any real recourse
15:08imirkin_: (i.e. no one who has to answer my dumb questions)
15:09mezo: hey, i just tried to compile latest version and get following error "/home/daniel/Downloads/nouveau/drm/nouveau/uapi/drm/nouveau_drm.h:30:17: fatal error: drm.h: Datei oder Verzeichnis nicht gefunden". anything i can do?
15:11karolherbst: imirkin_: :( yeah well. The trick is to write something wrong, so that somebody corrects you ;)
15:12karolherbst: mezo: this is some header stupidy we do, you can remove that include
15:12karolherbst: mezo: but, you need to build nouveau inside drm anyway
15:12karolherbst: top dir is building a userspace library
15:18mezo: how to build noveau inside drm?
15:30mezo: worked ;)
15:39imirkin_: karolherbst: nha appears to side with my interpretation of the spec (i.e. that nouveau is right, the app is wrong)
17:23rhn: hi! I tested valgrind-mmt - it's mostly fine, but there's a syscall #define problem
17:23rhn: *on ARM64
17:24rhn: dirty workaround: http://wklej.org/id/2906465/
17:25rhn: real reason: mmt_trace.c assumes the presence of __NR_open among other things, which are commented out in include/vki/vki-scnums-arm64-linux.h
17:28imirkin_: rhn: send a PR.
18:22benwaffle_: when i run weston and then epiphany (a webkit browser) my GPU locks up
18:22benwaffle_: kernel: nouveau 0000:01:00.0: fifo: read fault at 0005c00000 engine 00 [PGRAPH] client 04 [DISPATCH] reason 0a [COMPRESSED_SYSRAM] on channel 5 [003fb01000 systemd-logind]
18:22benwaffle_: kernel: nouveau 0000:01:00.0: fifo: gr engine fault on channel 5, recovering...
18:22imirkin_: good one...
18:22imirkin_: what gpu is that?
18:23benwaffle_: GTX 460v2 (NVC0)
18:23imirkin_: like a GF114 or something?
18:23benwaffle_: whats that
18:23imirkin_: look at your 'lspci -d 10de:' output and you'll see what i mean
18:23benwaffle_: yep GF114
18:24imirkin_: either way ... fun. that shouldn't happen. if a texture is ever allocated in sysram we shouldn't be trying to do compression on it
18:24imirkin_: what kernel are you on?
18:25imirkin_: and what libdrm do you use?
18:25benwaffle_: kernel 4.7.7-1-ck (also locks up w/o ck patches)
18:25benwaffle_: libdrm 2.4.71
18:26imirkin_: i was hoping you were on some dumb version of those. but you're not.
18:26imirkin_: and what mesa version?
18:26imirkin_: yeah ok. i got nothin'
18:26imirkin_: how reproducible is this?
18:27imirkin_: could you try to apitrace the epiphany thing and see if replaying the trace also triggers the same issue?
18:31benwaffle_: imirkin_: do i hit ^C once it locks up?
18:32imirkin_: benwaffle_: i guess yea
18:35benwaffle_: error: unable to open display
18:36benwaffle_: WAYLAND_DISPLAY is set tho
18:37imirkin_: oh, wayland... probably need to eglretrace?
18:37benwaffle_: apitrace trace --api egl ?
18:37benwaffle_: oh its a command
18:37imirkin_:has never used wayland
18:38imirkin_: i dunno what the quirks are
18:38benwaffle_: still same error
18:41benwaffle_: same lock up in X
18:54benwaffle_: imirkin_: if it helps, Xorg is stuck in a loop calling ioctl(DRM_IOCTL_NOUVEAU_GEM_CPU_PREP) = ERESTARTSYS
18:54imirkin_: well, that's just coz there was an error on the channel
18:55benwaffle_: the only thing in the apitrace is glXQueryServerString
18:56benwaffle_: i dont think nouveau ever worked on my gpu...
18:56imirkin_: probably it hates your software stack. dunno.
18:56imirkin_: it'd be odd for it to not work with your gpu - GF114 is mildly common, and i'm fairly sure it's worked reasonably for others
20:09karolherbst: ... just found out my new phone is a middle eastern device... the heck
20:14imirkin_: karolherbst: so... 2 people in favor of my view of the universe wrt that RGBA4 thing
20:14karolherbst: saw it
20:14imirkin_: karolherbst: feel free to point the developer at the thread in question
20:17karolherbst: mupuf: fyi list of fna based games: http://www.flibitijibibo.com/index.php?page=Portfolio/Tools#01_FNA.txt
20:17karolherbst: and I am surprised I have more than 10 of those :D
20:17karolherbst: dust ran without issues on nouveau though
20:30imirkin_: Riastradh: ping on the doc :)
20:49karolherbst: does anybody have a really fast downlink to china? :D
20:50karolherbst: yo, when tor downloads faster than your "ISP" ...
21:14benwaffle_: imirkin_: i'm back, how else can i debug this
21:15imirkin_: sorry, i don't have a ton of experience debugging things like that
21:16karolherbst: benwaffle_: what is your kernel version by the way?
21:16karolherbst: ohh 4.7
21:16benwaffle_: hmm ok glxgears locks up the gpu after running for 5 sec with artifacts
21:17imirkin_: lol, something's seriously wrong then
21:17karolherbst: benwaffle_: mind disabling ksm?
21:17karolherbst: no clue
21:17imirkin_: ksm = kernel-shared memory
21:17benwaffle_: you mean kms?
21:17imirkin_: it's a thing that tries to be clever for VM's
21:17karolherbst: kernel sampe page merging
21:18karolherbst: no idea what could cause "COMPRESSED_SYSRAM" otherwise
21:19imirkin_: karolherbst: it's in reference to the compression bits on PTE entries
21:19imirkin_: anyways, i don't think KSM is involved here
21:20imirkin_: my guess is there's some serious weirdness in either the memory setup or ... something
21:20karolherbst: most likely
21:20benwaffle_: what do i echo to run
21:20karolherbst: I guess 0
21:20imirkin_: benwaffle_: check that it's 0 - i bet it already is
21:20benwaffle_: it is
21:20imirkin_: benwaffle_: two debugging things...
21:21imirkin_: (a) https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c#n253 - change this to false.
21:21imirkin_: i.e. bool compressed = false;
21:21imirkin_: (b) try booting with nouveau.config=ltc=0
21:23benwaffle_: both together?
21:24imirkin_: in any combination you like
21:25benwaffle_: ltc=0 causes glxgears to have worse artifacts but its not locking up
21:25imirkin_: are you sure you haven't hit the board with a hammer at one point or another? :)
21:25benwaffle_: hm if i run epiphany it locks up
21:25imirkin_: it's nothing if not consistent
21:26benwaffle_: gr: DATA_ERROR 000000da  ch 8 [003f9c3000 glxgears] subc 0 class 9097 mthd 0d78 data 00000028
21:26benwaffle_: fifo: write fault at 000000b000 engine 04 [BAR1] client 08 [BAR_WRITE] reason 05 [PAGE_SYSTEM_ONLY] on channel -1 [003ff0c000 unknown
21:28imirkin_: 0d78... is ...
21:28imirkin_: why is 0x28 a data error? i disagree!
21:28benwaffle_: imirkin_: the number after data changes each line
21:29karolherbst: maybe it is just a super weirdo card...
21:29karolherbst: benwaffle_: do you know if nvidia works?
21:29benwaffle_: karolherbst: yep
21:29benwaffle_: nvidia works fine
21:29benwaffle_: imirkin_: the number after data is one of 00000016 00000028 0000002a 00000050 00000052 000000a2
21:31imirkin_: presumably mthd does too
21:31benwaffle_: nope always 0d78
21:31imirkin_: oh hm
21:31imirkin_: probably it verifies something then
21:31imirkin_: which errors out
21:31imirkin_: and it's reported against VERTEX_BUFFER_COUNT since it's the actual "go" action
21:31imirkin_: when it starts a draw
21:32imirkin_: anyways... from the sounds of it, your PTEs are seriously messed up
21:32imirkin_: we probably don't properly reset some MMU parameter
21:32benwaffle_: whats a PTE
21:32imirkin_: page table entry
21:32imirkin_: the GPU has a MMU
21:33imirkin_: so we're clearly doing something very wrong at a very low level
21:33imirkin_: which is trickling down into random shit failing
21:34benwaffle_: mesa wants pthreadstubs but i dont have that...
21:34imirkin_: if you're interested in debugging this further, i'd recommend taking a mmiotrace of the nvidia driver
21:34imirkin_: and mailing that to email@example.com (xz -9'd)
21:34benwaffle_: who's on the other end
21:34imirkin_: and then begging skeggsb to have a look at it to see if there's something obvious we're forgetting
21:35imirkin_: it's a shared account we use for collecting these things in a semi-central place
21:38benwaffle_: should i still compile mesa and set that bool to false?
21:40imirkin_: benwaffle_: worth a shot, but i doubt that's your issue
21:40benwaffle_: ok ill just do an mmiotrace
21:42imirkin_: ajax: your expertise is required on https://bugs.freedesktop.org/show_bug.cgi?id=98030
21:42imirkin_: or probably airlied --^
21:42imirkin_: i dunno who knows stuff, but i def know i don't :)
21:49mupuf: well, looks like phoronix contacted Khronos already
21:49imirkin_: very unfortunate.
21:50mupuf: they do care about mesa more than you think though
21:51RSpliet: sure, but MS will try and veto the hell out of "free conformance tests for OSS" :-P
21:53RSpliet: if only there was some sort of free software foundation that could help with the (relatively modest) financial side of this
21:55mupuf: RSpliet: modest? 15k per gen?
21:55RSpliet: that's a lot measured on my salary
21:56RSpliet: not a lot measured in revenue for Canonical, Red Hat, Suse and other parties with interest
21:56mupuf: that;s the budget for 10 years for the xorg foundation
21:57mupuf: there 26 GPUs that need to be certified :D
21:58airlied: theyve indicated in the past possibility of access to cts for free
21:58mupuf: that's about $400k
21:58RSpliet: All Adopters pay a one-off fee to access the Conformance Tests for a particular version of an API. The Adopters Fees are officially specified in the Khronos Group Conformance Test Process and enable an Adopter to submit an unlimited number of products for that API (and any earlier versions as indicated in the table below).
21:58airlied: for gpus that are already certified to that lvl
21:58RSpliet: submit an unlimited number of products
21:58mupuf: RSpliet: oh, right
21:58airlied: so if nvidia have gl 4.5 then anyone else could on nvidia hw
21:59mupuf: so, it is $15k per gl version then
21:59mupuf: airlied: money-wise, yeah, they should be OK with this. But ... who knows?
21:59airlied: but say gl on hw where only gles or 4.5 where only 4.4 was paid for previously
22:00airlied: not sure where it got to
22:04imirkin_: i'd rather xorg foundation not waste money on this junk
22:04imirkin_: just create a new api, call it Libre3D and move on
22:08RSpliet: well, if the CTS can actually contribute to squashing more bugs and thus a higher driver quality, then maybe there's some parties interested... would the CTS be that thorough?
22:09imirkin_: from the comments i've heard, CTS has a ton of bugs itself
22:09RSpliet: I knew I shouldn't've been optimistic
22:10mupuf: yeah, everyone patch it in their own way, AFAIK
22:10imirkin_: that said, i'm sure it does reveal real failures in mesa
22:11imirkin_: however given the state of nouveau, i would have no interest in getting any serious certifications for it
22:24benwaffle_: imirkin_: >Tell also what display connectors you have, what kind of monitors you have connected to what outputs, whether it has tv-in/out, and what display mode you used
22:24benwaffle_: help pls
22:25imirkin_: that doesn't matter
22:26imirkin_: including your vbios could be beneficial though
22:26imirkin_: (which you can get from nouveau via /sys/kernel/debug/dri/0/vbios.rom)
22:27benwaffle_: no such file
22:27benwaffle_: oh wait nouveau
22:28imirkin_: or you can get it from blob using envytools' nvagetbios iirc
22:32imirkin_: now you just have to get skeggsb to look at it
22:32benwaffle_: hey skeggsb
22:33imirkin_: unfortunately he's had bigger fish to proverbially fry of late
22:37benwaffle_: imirkin_: should the mmiotrace have lspci output in it
22:37benwaffle_: because mine has no LSPCI lines
22:37imirkin_: yeah, it starts out with the list of pci devices
22:37benwaffle_: it has PCIDEV
22:37imirkin_: it should be 10-100MB in size if you did it successfully
22:37imirkin_: and 1kb if you did it unsusccessfully
22:37imirkin_: ok cool. hopefully you xz -9'd it :)
22:39imirkin_: sounds like you did everything right
22:39imirkin_: sorry nouveau is such fail for you =/
22:39benwaffle_: hopefully y'all can fix it
22:39mupuf: gnurou: seems like there are serious regressions on linux 4.8 for the tk1
22:40mupuf: let's dump all the info and reboot on the newest kernel
22:40mupuf: err, the safe kernel
22:45mupuf: gnurou: https://paste.pound-python.org/show/booljSieMx8P6mFxkrPz/
22:46mupuf: "Tegra clk 127: register failed with -17" sounds like the issue that starts them all
22:46mwk: ugh, for fuck's sake
22:46mwk: NV1's cliprects work differently to NV3's...
22:47mupuf: mwk: yeah!!! they had to rework it ;)
22:48mwk: but NV3's cliprects are perfectly sane and work exactly the way I expected
22:48mwk: this implies NV1's are... not sane
22:48mupuf: but you will not say it ;)
22:54mwk: cliprects are affected by canvas_config bit 4, whatever that is
22:54mwk:hasn't seen that one before
23:27fling: Does this mean the X driver is too old? -> (EE) Unknown chipset: NV124
23:28fling: Or are both git versions of kernel module and X driver needed?
23:29imirkin: fling: xf86-video-nouveau does not support maxwell yet. it should fail to load, and the X server should fall back to modesetting, which will support everything as desired.
23:30fling: imirkin: what is fall back to modesetting?
23:33fling: imirkin: 2. How are they using nv126? -> https://bbs.archlinux.org/viewtopic.php?id=217819
23:34imirkin: modesetting is another DDX driver, just like nouveau.
23:35imirkin: "they" are the modesetting ddx in all likelihood
23:35imirkin: but xorg should auto-fall back
23:35imirkin: unless you're forcing nouveau in your xorg.conf
23:35imirkin: in which case ... don't do that
23:37fling: imirkin: ok, found x11-drivers/xf86-video-modesetting
23:37fling: imirkin: thanks :>
23:37imirkin: it's part of xserver now
23:38fling: umm? Is not the package needed?
23:39imirkin: i don't think so
23:39imirkin: that package is from back when it was out-of-tree
23:41fling: Which version of xorg-server needed?
23:43fling: Looks like it was merged in 1.17 something
23:43fling: imirkin: thanks for the info!
23:44fling: imirkin: does this look good? -> http://bpaste.net/show/401da7f9853a
23:44imirkin: not quite
23:45imirkin: (II) AIGLX: Screen 0 is not DRI2 capable
23:45imirkin: do you happen to have a super-old mesa?
23:45fling: anunnaki: ping ^
23:46imirkin: for GM204 you need ... 11.2 at least, i think?
23:48imirkin: yep. 11.2.0+