00:16 imirkin_: skeggsb: how's the nouveau rewrite coming?
00:17 airlied: he's currently sticking pins in small dolls, so probably not so bad :-P
00:17 imirkin_: dolls representing the multi-threading man?
00:18 airlied: one doll for each thread :-P
00:18 imirkin_: hehe
00:47 mupuf: imirkin, karolherbst: mupuf.org is down for some time, the HDD is dead
00:50 imirkin: doh!
00:53 mupuf: yeah, it is not even listed anymore by Linux when booting
00:53 mupuf: I asked OVH to replace it
00:53 mupuf: stuff should be back soonish
00:54 mupuf: too bad I did not want to do the migration to a new server last july and paid for another year
00:55 mupuf: now, I get to reinstall this server and another one in 6 mponths because there are cheaper deals now
00:55 mupuf: oh well
01:56 imirkin: librin: well, as i suspected - compiles fine on GK110+, fails on kepler (insufficient regs)
01:57 imirkin: hardly an excuse, but it's an explanation...
02:06 imirkin: hm ok. something very odd is happening.
02:16 imirkin: i think it has to do with trying to spill a phi node. urgh.
02:52 imirkin: right yeah ok. this problem feels semi-familiar.
02:53 imirkin: of course last time i seem to recall banging my head against the wall pretty hard before all the bad thoughts went away...
02:54 imirkin: basically we delete some instruction in the spill pass, but its def is sitting around on some random value's defs list due to value joining.
02:57 imirkin: iirc i solved that issue, but then got beat over the head by 20 other issues. let's see...
03:06 imirkin: yeah of course nothing is so simple
03:16 imirkin: [as an aside, f1 2015 still hangs]
03:25 nyef```: ... the amount of trouble I've had with a compiler deleting something that it shouldn't and consequently screwing up value semantics... in the past month alone...
03:25 imirkin: oh no - it's supposed to delete it.
03:25 nyef```: Lucky you.
03:25 imirkin: it just doesn't appear to do as complete a job as it ought to
03:25 imirkin: and there's a dangling reference somewhere
03:26 imirkin: and this stuff is SO CONFUSING
03:26 nyef```: In my case, it's been "no, it's not supposed to delete this because *reason*."
03:26 imirkin: instructions, values, valuedefs, all kinds of goodies
03:26 nyef```: On the other hand, someone else working on the same compiler ran into one where something got deleted twice, and the second time the system blew up.
03:41 imirkin: just need to build up a proper model of wtf is going on
03:42 imirkin: and then follow that up with Act II - fixing it
03:42 nyef```: I'm currently thinking that the best thing that I could be doing for the nouveau compiler at this point is to build a random tester for it.
03:47 librin: imirkin_: You say it compiles fine on GK110+, but fails on Kepler
03:47 librin: but... isn't GK110 still kepler?
03:47 librin:scratches head in confusion
03:47 imirkin: librin: kepler2 vs kepler1
03:47 imirkin: kepler2 has 255 regs, kepler1 has 63
03:48 tlvb: Is this the right place to ask for help when «Xorg fails to start with "(EE) [drm] failed to open device"» as in the troubleshooting docs, nouveau fails to load automatically or manually, and it's not one of the three causes listed (kms/drm version mismatch/drm not loaded)?
03:48 imirkin: tlvb: pastebin dmesg and xorg logs
03:48 librin: nvidia and their confusing internal naming schemes...
03:50 imirkin: librin: as it happens, the shader builds with NV50_PROG_OPTIMIZE=0
03:51 librin: imirkin: I wonder how many glorious screenworth of pixels per second that'd get me :D
03:51 imirkin: it looks like it's about 2x the instructions
03:51 librin: time to test!
03:52 imirkin: note that you need a debug build for that env var to do anything
03:52 librin: m'kay, time to recompile again, then
03:53 librin: good thing I got all those extra CPU coars to spare for that :)
03:53 imirkin: doesn't have to be -O0, just --enable-debug
03:53 librin: aye
03:54 tlvb: imirkin: dmesg: https://bpaste.net/show/540d73e26876 Xorg.0.log: https://bpaste.net/show/1e4e69317f88
03:55 imirkin: tlvb: there appears to be no mention of nouveau in your dmesg. it's probably not getting loaded, or is getting disabled.
03:56 imirkin: tlvb: among other things it appears that vesafb is being loaded, which iirc has had negative interactions with nouveau
03:56 imirkin: although you probably just have a nouveau.modeset=0 somewhere
03:56 tlvb: if I modprobe it manually, it fails, complaining about a buttons.ko (a dependency?): https://bpaste.net/show/8986c757c0db
03:58 tlvb: I'm doing the first attempt at getting X to run, so if there's any modesetting going on, it's in the default system. /proc/cmdline has no modesetting going on at least
03:59 imirkin: tlvb: perhaps your log level is set too low?
03:59 imirkin: tlvb: grep -r modeset /etc/modprobe*
04:00 tlvb: nothing in modprobe
04:00 imirkin: [ 10.626906] [drm] Initialized
04:00 imirkin: so it does try to load something
04:00 imirkin: ls -l /dev/dri
04:01 tlvb: no such file or directory
04:01 tlvb: drm kernel module does load automatically
04:01 tlvb: so it's no surprise that it can't find the card0 that's supposed to reside in it heh
04:14 imirkin: what what
04:14 imirkin: this makes no sense
04:14 imirkin: i fixed a minor spilling-related item. and now there's *no spilling* in the resulting shader??
04:14 librin: imirkin: holy excrement, it does run with NV50_PROG_OPTIMIZE=0
04:15 librin: painfully slow, though
04:15 imirkin: oh goodie. the results are messed up.
04:53 tlvb: imirkin: thanks for your time, I have in my searching yet to find a way to disable vesafb that does not seem to disable KMS entirely, apart from maybe compiling my own kernel ...and sometime here I noticed that it's almost six in the morning, and that it has to wait
08:02 pq: imirkin, the reason there is no other way to access the contents of a hw-GL capable buffer is that only the hw-GL/DRM driver may know how to access it. The only standard API we have to such a driver is OpenGL or Vulkan, since we do not have the video DDX drivers Xorg does, as display servers no longer have any hardware-specific code in the usual case.
08:02 pq: imirkin, it's pretty much the same as where Xorg with the modesetting driver is going: completely hw-agnostic display server.
08:03 pq: imirkin, I suppose one could compare the situation to asking "I made a GL texture, how do I read it without using OpenGL?"
08:07 pq: imirkin, the corollary of that is, if a Wayland compositor initializes a GPU driver so that it can access hw-GL buffers produced by apps, why would it not use GL itself to do the composite. Hence I do not believe you can find a Wayland compositor that would not use hw-GL itself while supporting hw-GL apps.
09:33 mupuf: here we go, new drive
10:18 karolherbst: mupuf: for reator?
10:55 mupuf: karolherbst: nope, mupuf.org
10:56 karolherbst: I see
12:25 kattana_: hei, stellarioum triggered a horrible memory violation with grsec kernel. Stellarium is able to start and display the world with atmosphere layer. As soon as I toggle atmosphere off, to have a black sky stellarium gets instantly killed.
12:26 kattana_: Whose's to blame here? Nouveau, Xorg, Stellarium? What I understand is that Stellarium uses Opengl and that kinda stuff to render things.
12:28 karolherbst: kattana_: it depends
12:28 karolherbst: for this someone would have to analyze in depth where this memory violation is coming from
12:28 karolherbst: valgrind helps here at least
12:28 kattana_: Celestia runs fine.
12:29 kattana_: karolherbst: how would in look like the valgrind command? Can you give an example?
12:29 karolherbst: I am no valgrind expert, there are enough tutorials for valgrind
12:31 kattana_: dmesg got post-mortem messages after the kill. They are all long number lines.
12:35 RSpliet: kattana_: nouveau can only be to blame if you're running the latest software (so a 4.9 kernel, mesa 13.0 or something...)
12:36 kattana_: RSpliet: kernel 4.3, mesa 13
12:36 RSpliet: Ah yes... theoretically your problem might be solved with a newer kernel (if it really is a mem violation) - in practice not so sure. You'd have to try that out
12:37 RSpliet: if it doesn't... try and get a gdb backtrace to see where this violation occurs within your application
12:37 RSpliet: maybe the shortest apitrace imaginable
12:38 RSpliet: and if you can, try Mesa 17 as soon as it's out (don't ask about the version jump... ;-))
12:38 kattana_: RSpliet: do you have a quick 'gdb' command to try?
13:33 RSpliet: kattana_: "gdb <application>", "r", make it crash, "bt"?
14:31 dboyan: imirkin, i started looking at fp64 today. The blob driver is generating ~2k of code for each of drcp, drsq and dsqrt respectively
14:31 dboyan: trying to understand what they do, starting from drcp, which seems the shortest
14:31 imirkin: errrr doubtful. or maybe it's uploading its library unconditionally.
14:31 imirkin: dsqrt should be a huge function that gets called
14:32 imirkin: drcp/drsq should be minor fixups to the rcp64h/rsq64h ops
14:33 dboyan: not really, the drcp code even doesn't use rcp64h
14:33 imirkin: uhhhhhh
14:33 imirkin: it used to!
14:34 imirkin: maybe they decided that those ops are insufficient? dunno =/
14:35 dboyan: also they are rather "huge" fixups rather than minor ones, i might write some C code to simulate the math
14:36 dboyan: i find the blob driver fond of generating huge code, it once unrolled one of my loops 85 times
14:38 imirkin: well, blob does unroll very aggressively
14:38 imirkin: iirc the fixups for drsq/drcp were on the order of 3-4 instructions before, and maybe 6 after the rcp64h/rsq64h op
14:48 dboyan: imirkin, https://people.freedesktop.org/~dboyan/rcp-nv.txt
14:48 dboyan: the drcp routine starts at 0xb8
14:49 imirkin: can i see the shader too?
14:50 dboyan: wait a minute
14:50 imirkin: it looks like it converts the value to a f32
14:50 imirkin: and then does the 1/x as a f32
14:50 dboyan: yeah, and convert that back to f64
14:51 imirkin: which makes little sense... the range on a f32 is so much lower
14:52 imirkin: although perhaps it looks at the mantissa and exponent separately
14:52 imirkin: in which case i guess it could make sense.
14:59 dboyan: imirkin, https://people.freedesktop.org/~dboyan/rcp_cs.glsl
15:00 dboyan: the network encountered some problem just now
15:17 imirkin: dboyan: aha, that's why. use 1.0LF
15:18 imirkin: although... maybe the 1 is supposed to get upgrade to double? not sure. either way, i'd recommend trying again with 1.0LF
15:19 dboyan: oh, well, haven't used fp64 before
15:20 dboyan: will try it later, if i still get such code, i'll use some older version of blob driver
15:21 imirkin: also try a non-compute shader
15:21 imirkin: they could use different rules, dunno
15:22 Tom^: imirkin: i was sort of planning todo so, but the reviews was kinda mixed so i got cheap and didnt buy it. sadly i cant find a place to pirate the linux version
15:22 imirkin: Tom^: ah ok. well it should actually work on your GK110 :) the issue that librin ran into was with RA, and that doesn't hit when you have more regs
15:22 Tom^: most people says its a stripped down version of the old civ V :P
15:22 Tom^: imirkin: i see
15:24 librin: FWIW, it's still very playable with shader compiler optimizations off, which prevents the crash
15:24 librin: I guess due to the whole "painfully CPU-bound" trait Civ games tend to have
15:24 Tom^: isnt that glthread out of tree patches applyable to nouvea/mesa ?
15:25 librin: no idea
15:25 Tom^: these http://www.phoronix.com/scan.php?page=news_item&px=GL-Dispatch-Mesa-Review
15:25 librin: but my point was that even with unpotimized shader code it's still very playable on my gk104
15:25 Tom^: yea
15:28 imirkin: it's not just unoptimized... it's de-optimized. the conversion stages are very much written with the later opt stages in mind
15:28 imirkin: a ton of unnecessary moves
15:29 Tom^: mmh i wouldnt know, i just get all excited like a kid with candy reading it =D
15:42 librin: imirkin: haha, why does that make think of -09 -funroll-every-loop -mrice -mabi=rice -omg-optimized :D
16:05 Tom^: holy moly gog has some nice sales today if you didnt know https://www.gog.com/promo/20170214_special_promo_from_wishlists_with_love
16:07 Tom^: i also took a picture of this tesla today http://i.imgur.com/BzoAAWV.jpg =D
16:09 pmoreau: :-D
16:09 pmoreau: I have to admit, I first thought you were talking about an NVIDIA card… :-p
16:09 librin: "damn, son!"
16:10 Tom^: haha
16:10 librin: ditto, I thought You were talking of an Nvidia card
16:11 pmoreau: As for the GoG sales, sadly nothing interesting that I don’t already have + no time to play them anyway… :-/
16:12 librin: € {{ slider.total().oldAmount }}{{ slider.total().amount }} You save {{ slider.total().save }} ({{ slider.total().discount }}%)
16:12 librin: I think this sale is tad broken
16:13 RSpliet: The Euro still exists right?
16:13 pmoreau: Not accepting cookies maybe?
16:13 librin: yes, but that's exactly what I see on the site
16:13 librin: along with a load of other similarly looking stuff
16:14 pmoreau: IIRC, I was having that issue if I wasn't accepting cookies.
16:14 librin: and IDK, I don't block cookies nor scripts in GOG
16:14 pmoreau: Hum, dunno then.
16:16 librin: aww well...
16:18 librin: Tom^: was that pic taken in Sweden?
16:18 Tom^: yea
16:19 librin: ah, okay
16:25 imirkin: there was a photo of gvr's car, whose license plate was "PYTHON" or something along those lines, parked next to another car in the google parking lot which read "JAVASUX"
16:27 librin: I'd love to see THAT
16:27 RSpliet: http://img-9gag-ftw.9cache.com/photo/a8Y5ANY_700b.jpg
16:28 imirkin: i dunno if it ever made it anywhere public
16:45 Tom^: RSpliet: haha
16:45 Tom^: RSpliet: its yours?
16:46 RSpliet: I'm afraid that car would not reflect the financial situation of a PhD student like myself
18:01 pmoreau: RSpliet: Do they sell them along the required firmware?
18:25 pmoreau: Ah! It looks like function calling is working again!
18:26 pmoreau: If so, I was just being stupid, trying to manually move the values for the args and the res, rather than setting them as srcs and defs of the call insn…
18:27 pmoreau: Thankfully the TGSI translation helped me found my mistake. :-)
18:27 imirkin_: oops :)
18:30 pmoreau: So, if I can finish supporting the OpSwitch statement (and do some cleanup), I should be ready to send a RFC.
18:34 imirkin_: wow, really?
18:35 imirkin_: does that include proper SSA handling and such?
18:38 pmoreau: Hold on, this is only a RFC for the clover part and adding a SPIR-V linker! :-D
18:39 pmoreau: There will be absolutely no SPIR-V support for Nouveau in it.
18:39 imirkin_: oh.
18:40 pmoreau: Though I will probably try to send one in a not too distant future, at least to introduce the very basic stuff. Most likely without a prefer SSA handling.
18:40 pmoreau: If that sounds reasonnable.
18:40 imirkin_: yeah, it's reasonable
18:40 imirkin_: btw, i looked into your question
18:40 imirkin_: about while loops
18:40 imirkin_: and the such
18:40 pmoreau: Oh, cool!
18:40 imirkin_: before RA runs
18:40 imirkin_: there's a pass which computes the ins/outs of a BB
18:41 imirkin_: and this is used to extend live ranges
18:41 pmoreau: Right, I think I had a look at it… maybe
18:41 imirkin_: if you're seeing the issue that you're seeing
18:41 imirkin_: then that means for one reason or another, that logic isn't working properly
18:41 imirkin_: it's sensitive to edge types, and perhaps your edge types aren't configured the way the system wants
18:43 pmoreau: IIRC, one thing I came to think, was that the way it worked, it would never compute the correct result if there is more than one BB in the loop, as it does everything in a single pass rather than iterating until convergence.
18:44 imirkin_: that seems unlikely
18:44 imirkin_: but possible.
18:44 pmoreau: I would need to have another look.
18:45 pmoreau: But I think I had the proper edges type (if i understand the differences correctly).
18:46 pmoreau: Did you had a quick look at the code I sent you? It contained the edge types I thought should be used there.
18:46 imirkin_: not really, tbh =/
18:46 pmoreau: No problem, thanks for having a look anyway. :-)
18:46 imirkin_: i'm sorry, but at this point, you basically just have to read the code
18:46 imirkin_: i'm not sufficiently knowledgeable in all the details to just "know"
18:46 pmoreau: Sure
18:47 imirkin_: and calim has long forgotten all of these details as well
18:47 pmoreau: The spilling issue seems like a fun topic as well… :-D
18:47 imirkin_: don't make the mistake of thinking that the current code is correct - chances are pretty good that it's not.
18:47 imirkin_: spilling has been a thorn in the compiler's side for a LONG time
18:48 imirkin_: both calim and i have made countless fixes to it, and yet it remains broken
18:48 imirkin_: i think i have a handle on the underlying cause of the current problem
18:48 imirkin_: but not really a fix yet
18:48 imirkin_: it'll take a weekend of intense hacking to work it out
18:48 imirkin_: in the end, i'm sure it'll be a one-line fix.
18:51 karolherbst: \o/ finally
18:51 imirkin_: ?
18:51 karolherbst: reclocking while gpu is suspended
18:51 imirkin_: nice!
18:51 pmoreau: imirkin_: :-/
18:52 pmoreau: karolherbst: What happens in that case? You cache the new value and submit it once the GPU resumes?
18:52 karolherbst: imirkin_: and all the other stuff: restore clocks on resume, no hang in pstate while suspended, ...
18:52 karolherbst: pmoreau: basically, yeah
18:52 mlankhorst: would be only sane way
18:52 karolherbst: https://github.com/karolherbst/nouveau/commits/clk_update_v2
18:52 imirkin_: karolherbst: yay. very welcome :)
18:53 karolherbst: all the clk related patches
18:53 pmoreau: Who doesn’t like hangs… :-D
18:53 karolherbst: pmoreau: basically I've added a new "nvkm_clk_update" interface which sets up all the stuff
18:53 karolherbst: and even recalculates max voltage and lowers the clocks, when also the voltage drops
18:53 karolherbst: but this is for later
18:54 karolherbst: I mean, to do that automatically
18:54 pmoreau: So, this brings you once step closer to dynamic reclocking I guess?
18:54 karolherbst: no
18:54 karolherbst: :D
18:54 karolherbst: it
18:54 karolherbst: it's unimportant for that
18:54 Yoshimo: The Nintendo Switch features a Tegra chip, might make it easy to run a linux later
18:54 karolherbst: it makes it a little easier
18:54 pmoreau: Well, dynamically hanging wouldn't be that great!
18:54 karolherbst: sure
18:54 mlankhorst: nv130 isn't even in the feature atriix?
18:55 imirkin_: nouveau should expose ES 3.2 on those :)
18:55 karolherbst: pmoreau: the only missing thing for dyn reclocking was to map PMU mem counter -> nvidia mem load
18:55 karolherbst: and I know that now
18:55 karolherbst: the implementation is basically there already
18:55 karolherbst: I just need to implement the pstate dynamic reclocking
18:55 pmoreau: Ok
18:55 karolherbst: because this is a bit easier and requires the PMU to know about the currently set clocks
18:56 karolherbst: *messier
18:56 karolherbst: it's more a thinking type issue, not coding
18:56 karolherbst: pmoreau: https://github.com/karolherbst/nouveau/commit/037129aaae27e144f7b96402497573060ef8810f
19:04 < manjaro-web|9954> hello here
19:04 < manjaro-web|9954> i can't get oss driver works with my screen
19:05 < manjaro-web|9954> i'm looking for help
19:06 < manjaro-web|9954> anyone listening ?
19:12 karolherbst: imirkin_: do you want to try to get nouveau broken with my branch or should I just post it to the ML?
19:15 imirkin_: karolherbst: not sure i understand your question
19:20 karolherbst: okay, I broke it myself with my other changes already
19:20 imirkin_: "yay" :)
19:20 karolherbst: yeah, but this was related to changing the boost level while suspended
19:21 karolherbst: mhh
19:24 karolherbst: oh well
19:24 karolherbst: this is for another series then
19:24 karolherbst: imirkin_: I meant if you wanna test it a bit
19:24 karolherbst: pmoreau: you also have a laptop, don't you?
19:25 pmoreau: I indeed do
19:25 pmoreau: Even two of them! O.O
19:25 karolherbst: wow
19:25 karolherbst: wanna test my branch?
19:25 pmoreau: Sure!
19:25 imirkin_: karolherbst: pass :p
19:25 karolherbst: https://github.com/karolherbst/nouveau/commits/clk_update_v2
19:26 karolherbst: goal: hang nouveau by using the pstate file while suspended
19:26 karolherbst: or something
19:26 pmoreau: Will have a once I'm done having dinner.
19:26 pmoreau: *try
19:26 pmoreau: Should work on every generations which can reclock, right?
19:27 karolherbst: yes
19:27 karolherbst: and reclocking should be tested in general as well
19:28 pmoreau: Ok, still manual I guess, or do you have some dynamic patches there as well?
19:28 karolherbst: manual
19:28 karolherbst: okay, I've found one issue already
19:28 karolherbst: but I don't know if the current code can do this
19:28 karolherbst: when I plug out the power, should it switch pstates?
19:29 karolherbst: it seems like nouveau doesn't update it's AC/DC state here
19:30 karolherbst: okay, this indeed works
19:30 karolherbst: on nouveau stock
19:34 karolherbst: why does this commit break it? https://github.com/karolherbst/nouveau/commit/986347bf685139525612842dc5dafe8981992a47
19:34 karolherbst: ohh wait, it works....
19:34 karolherbst: huh
19:36 karolherbst: lol
19:36 karolherbst: it doesn't work when the GPU is in use
19:38 karolherbst: and another issue found
19:38 karolherbst: https://gist.github.com/karolherbst/a9dc4b02b2c5568f1d13648496701ff1
19:46 karolherbst: fixed the reclock while suspending issue (I hope)
19:55 whompy: Karolherbst: want testing from an old tesla?
19:55 karolherbst: every testing is good
19:55 karolherbst: currently I detected the issue, that when my gpu is suspended and I want to lock my plasma session, the GPU is turned on again and X freezes....
19:55 karolherbst: fun
19:56 whompy: Interesting. This for a prime setup?
19:58 karolherbst: yeah
19:58 karolherbst: I am sure this is logind related though
20:00 whompy: Hm. Mine is from the single GPU era, so I believe I'm out for this round of reclock testing
20:00 karolherbst: well
20:00 karolherbst: desktops can be suspended as well
20:00 karolherbst: but this is less critical
20:00 karolherbst: should also work though
20:02 karolherbst: why the heck, does locking the session wakes up the GPU....
20:23 karolherbst: hum... this is getting annoying
20:24 pmoreau: karolherbst: Oh, it needs "dynamic Optimus" support? Cause I need to manually power on/off the card (on both).
20:24 karolherbst: uhm
20:24 karolherbst: you can also suspend your machine
20:25 karolherbst: it shouldn't matter
20:25 karolherbst: and it should work with everything
20:25 pmoreau: Ok
20:25 karolherbst: this has like a high potential to break stuff
20:25 karolherbst: Lekensteyn: I have a runpm problem
20:25 karolherbst: Lekensteyn: https://github.com/karolherbst/nouveau/commit/296bc547a472517cf959342a014d50a10d30bb5f
20:25 karolherbst: I have to keep the GPU awake where the magic_function_call calls are
20:26 karolherbst: but I can't use pm_get_sync(), cause I can't
20:26 karolherbst: and I have to make sure, that the gpu is on when clk->func->update is called
20:28 airlied: karolherbst: are you too far down some rabbit hole to use pm_Get?
20:28 airlied: what context is this running in, maybe you need to pm_get_sync a lot earlier
20:32 karolherbst: airlied: it may or may not run in a context where the gpu gets resumed
20:32 karolherbst: what I have to ensure is, that the GPU isn't getting suspended while I call update
20:37 karolherbst: airlied: the plasma5 screen locker does this for example: https://gist.github.com/karolherbst/dde204e4c1de668e06fc26ac766c0a6e
20:46 karolherbst: airlied: any suggestions what I could do here? all the other code in that function has to be called even when the gpu isn't suspended
20:51 Lekensteyn: karolherbst: is it possible to schedule some work to do this?
20:51 Lekensteyn: can you do the update asynchronously?
21:07 imirkin_: skeggsb: have you tried replaying hakzsam's F1 2015 trace yet to test out your recovery logic?
21:09 susan34: Hi. question. i've an nvidia gpu card. when i start, i get this : Unknown chipset: NV117 then, Falling back to old probe method for fbdev. making the rendering slow. any tip please ?
21:09 imirkin_: susan34: you can either grab xf86-video-nouveau from git, or use modesetting.
21:09 susan34: you mean : my xf86-video-nouveau is not up to date, isn't it ?
21:10 imirkin_: i haven't cut a release yet that includes maxwell support
21:10 susan34: ok. how to swith to modesettings ? (does it work with X ?)
21:10 imirkin_: xf86-video-modesetting is shipped as part of X nowadays
21:10 imirkin_: what version of Xorg do you have?
21:10 imirkin_: and do you have mesa installed?
21:12 susan34: xserver_xorg-server-1.19.0
21:12 imirkin_: hum, that should be good enough.
21:12 imirkin_: can you pastebin your dmesg and xorg logs?
21:12 susan34: yes, mesa, and i recently add the flag : +MESA3D_CONF_OPTS += --enable-texture-float
21:13 susan34: https://1fichier.com/?ypn1iwobfo : files system/Xorg.0.log and system/dmesg
21:13 imirkin_: bleh
21:13 imirkin_: now i have to untar stuff?
21:13 susan34: note that i don't really own this card, i'm just the maintener of a linux distribution.
21:13 susan34: yes
21:13 imirkin_: can you make it so i can just view it in browser?
21:13 susan34: ok
21:14 imirkin_: ah, well that makes it more likely that you'll be able to better deal with package issues :)
21:14 susan34: xorg : http://pastebin.com/raw/gpgWLmnG
21:15 imirkin_: looks like it did fall back to modesetting as i expected
21:15 susan34: dmesg : http://pastebin.com/raw/qgPVy5kY
21:15 imirkin_: [1044093.486] (EE) AIGLX: reverting to software rendering
21:15 imirkin_: that's a bit surprising
21:15 susan34: yes, and the interface is then slow.
21:15 imirkin_: which makes sense... glamor didn't get initialized for some reason
21:16 imirkin_: i don't suppose you built xorg without glamor for some reason?
21:17 susan34: perhaps because i don't know what glamor is ;-) I'm looking. i possibly forgot that.
21:17 susan34: arg ... --disable-glamor
21:17 imirkin_: oops :)
21:18 imirkin_: that said, i'd kinda recommend grabbing the git version of xf86-video-nouveau over using xf86-video-modesetting. but if you have to use a released version, then you definitely want glamor enabled there.
21:19 imirkin_: glamor is the generic accel layer that implements EXA using GL
21:20 imirkin_: also make sure that mesa is compiled with egl support
21:20 imirkin_: (and gbm as well)
21:20 susan34: i can upgrad the realase. however, i'm based on buildroot, a tool to build distribution. it looks like glamor is not enabled because i've not enabled BR2_PACKAGE_LIBEPOXY
21:21 imirkin_: ok... libepoxy is a tiny lib
21:21 imirkin_: with no other dependencies
21:21 imirkin_: which makes writing GL code slightly more palatable
21:23 susan34: so, i will add BR2_PACKAGE_LIBEPOXY to enable glamor, and that should work. i'm building it and let the people tries. thanks a lot.
21:23 imirkin_: double-check your mesa build config
21:23 imirkin_: to ensure that egl and gbm are enabled
21:24 imirkin_: coz glamor won't work without that
21:25 susan34: mesa : --disable-egl HAVE_GBM TRUE... ok, so i have to enable egl too. gpu drivers are a hell to me ;-)
21:25 imirkin_:wonders how gbm can be enabled without EGL
21:26 nyef```: ... by reorienting the p in your text-console mouse driver?
21:27 imirkin_: heh
21:28 susan34: imirkin_, i think that HAVE_GBM TRUE is the default value, but later in the configuration file, --disable egl probably set it to false
21:28 imirkin_: ah ok, could be
21:29 imirkin_: anyways, you'll want glamor for modern AMD parts as well
21:29 imirkin_: since they've completely dropped driver support for them (in response to there not being 2D accel hw on those parts either, so can't do much better than glamor anyways)
21:40 kattana_: I boot blind, until blindly typing 'startx'
21:40 kattana_: which option did I miss?
21:43 imirkin_: CONFIG_DRM_FBDEV_EMU or something
21:43 imirkin_: CONFIG_DRM_FBDEV_EMULATION=y
21:46 kattana_: wow
21:51 kattana_: imirkin_: I read 'legacy' in the description antd thought had to do with ancient stuff.
21:51 imirkin_: yeah, someone jumped the gun on calling it legacy ;)
21:56 nyef```: "Legacy code, n.: Software that exists. Antonym: Vaporware."
21:57 imirkin_: devil's dictionary?
21:58 nyef```: Made up on the spot, as far as I know, but it might have been in the Devil's DP Dictionary.
21:58 nyef```: (Or the "Computer Contradictionary", as I believe the other edition is called.)