00:14haagch: now OpenGL doesn't work at all with that mesa version...
00:14haagch: it works as root
00:15imirkin_: ah. probably a change in permissions?
00:15imirkin_: for /dev/dri/renderD*
00:15imirkin_: getting it directly vs getting it through the X server?
00:15haagch: no, not renderD128
00:15imirkin_: iirc i hit that recently as well
00:15imirkin_: oh - make sure you update libdrm
00:15imirkin_: iirc xexaxo1 recently broke things in mesa s.t. it requires a fresher libdrm in your type of situation
00:16imirkin_: yeah that's clearly wrong
00:17haagch: apparently gnurou did that originally because wayland (?) uses an ioctl called FLINK that is not supported by render nodes
00:17imirkin_: flink is for dri2-only
00:19haagch: ah, modesetting is using dri3 now on tegra, but DRI_PRIME=1 doesn't work... probably because of the renderonly hacks
00:23mupuf: haagch: well, that sounds insane. Why would weston use dri2 primitives when it could use dmabuf?
00:23mupuf: and even better than this, weston does not even do this
00:23haagch: not sure, I never tried it
00:23haagch: maybe it was with X too
00:23mupuf: it lets mesa do it for itself
00:23mupuf: yeah, it is likely because of X
00:23haagch: in the patch on the mailing list it is .gpu_fd = drmOpenWithType("nouveau", NULL, DRM_NODE_RENDER),
00:23mupuf: Wayland compositors do not have to deal with this
00:25haagch: i just assumed it was on wayland, because I had no trouble with using renderD128 on X like that
00:33haagch: finally found a project with compute shaders on github that compiles and runs
00:33imirkin_: oh sorry - i could have referred one
00:36haagch: and what did you want to see? atom_count in gallium hud?
00:36imirkin_: any of the counter-related counters
00:37imirkin_: [don't have a list on-hand]
00:37haagch: when trying atom_count, it spams gallium_hud: all queries are busy after 8 frames, can't add another query
00:37imirkin_: atom_count sounds like it should be fine
00:37imirkin_: hrmmmm ok
00:37imirkin_: ouch, ok
00:37imirkin_: looks like it returns the wrong queries
00:38imirkin_: can you pull up this file: src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
00:38imirkin_: and add a NVEA_3D_CLASS right above both instances of NVF0_3D_CLASS ?
00:38imirkin_: i think there might be another edit...
00:39imirkin_: ah yeah. also in nvc0_hw_metric_get_query_result.
00:40imirkin_: oh, and nvc0_hw_sm_get_program.
00:40imirkin_: (NVEA is like NVF0 as far as all these things are concerned)
00:44haagch: no errors, but the graph is constant 0
00:45imirkin_: yeah, that's expected
00:45imirkin_: try something like...
01:10NanoSector: that looks bugged
01:11imirkin: i dunno. seems right to me.
01:11imirkin: haagch: send patches :)
01:12imirkin: haagch: did you also test that compute works OK in general?
01:12haagch: i tried this and it works https://github.com/tcoppex/gl-compute-c99
01:12haagch: with an override for 4.4
01:12nyef: No, no. It's obviously buggy. Why else would the FPS be as low as 15?!? d-:
01:12imirkin: haagch: excellent!
01:13NanoSector: nyef: heh. looks like it's missing textures
01:13nyef: Wouldn't not having to do texture mapping make it faster?
01:14imirkin: haagch: make sure you have libtxc_dxtn for textures :)
01:14haagch: nah, that's just how tesseract looks like
01:14imirkin: haagch: also you should be able to adjust pstates via debugfs
01:14haagch: yes, I set it to 0f, 852 MHz
01:14imirkin: haagch: ah, you missed a (very minor) spot
01:15imirkin: haagch: in hw_metric.c iirc
01:15imirkin: haagch: if you want to mail it out, i can apply. otherwise i can stick my name on it. don't really care either way.
01:16haagch: you do it
01:26imirkin: haagch: i'll give you a "final" thing to test shortly, should be largely identical to what you have now
01:26haagch: i just noticed i ran tesseract with 1366x768 and upscaling
01:26haagch: quite heavy for the poor tegra gpu: https://i.imgur.com/QY7tTH4.png
01:26mupuf: haagch: congrats!
01:26mupuf: Definitely will take advantage of this as soon as I can to do proper testing@!
01:26mupuf: 7 fps is quite ... terrible :D
01:28haagch: archlinuxarm needs more games in their repository
01:28haagch: not even xonotic is there.
01:32haagch: hm, opengl via egl in weston works with renderonly, but opengl in xwayland does not
01:35haagch: xwayland doesn't work at all...
01:36imirkin: haagch: ok, patch sent to ml
01:42haagch: Disabling glamor and dri3, EGL setup failed
01:48haagch: messed up rendering after suspend doesn't always happen, but often. ttys are messed up too. changing resolutions fixes it.
01:48haagch: and now I have to sleep
02:34nyef: ... If I said "GeForce4 440 Go", what would your reaction be? (-:
02:37nyef: (I'm fairly sure that I have such a thing... and that the only problems with the system are the backlight and that the under-warranty replacement battery was improperly installed to the point that the system could drop from s2ram to power off by the power of a good shaking.)
02:41nyef: ... And that the test script that I'm now using to poke around with HDMI InfoFrames dates back to when I was trying to get nouveau to work on said hardware. Something to do with TMDS registers.
05:00imirkin: nyef: NV17 or NV18 or whatever? should work fine.
05:00imirkin: the display is totally different of course
05:01imirkin: hakzsam: could you look at my NVEA query patch when you get a chance?
05:02imirkin: haagch: are you saying that you were getting issues with my patch? or just getting issues in general?
05:05nyef: imirkin: NV17, I think. On the other hand, I bought it *new*. This was before the Linux kernel could suspend reliably on two CPUs.
05:05nyef: I ended up running coLinux on it in order to get a usable software platform and working device drivers.
05:07nyef: On my list of things to try someday is tearing apart the display and seeing if the backlight can be repaired somehow. I know that it's not the inverter board because I've already replaced that.
05:08nyef: The machine itself has already come in handy once within the past couple of years, as a 64-bit x86 with USB, when I managed to kill my then-primary system... by alcohol poisoning.
05:08nyef: ... Might have been two and a half years ago.
05:19nyef: I'll be able to check in about a week.
09:14haagch: imirkin: i think the messed up rendering after suspend is since i upgraded to a linux 4.10 rc, with 4.5 it worked fine
09:14haagch: imirkin: and i think with the renderonly mesa branch xwayland never worked, but I'm not sure about that
09:48inglor: imirkin: Ok after compiling with debug symbols the lib32-mesa-libgl and lib32-mesa packages the game now runs succssfully. Could this be a race condition which is sorted once the debug symbols are there?
12:20infinity0: hey guys, i'm getting hit by a weird issue where chromium and video players both freeze randomly
12:20infinity0: i can ctrl-C the process but otherwise the GUI parts are not responsive. the audio continues to play in the background though
12:20infinity0: how would i debug this? pretty sure it started after i switched my gfx card back
12:20infinity0: (from intel integrated, to nvidia with nouveau, that is)
12:23RSpliet: infinity0: your kernel logs likely mention something like CTXSWITCH_TIMEOUT
12:24RSpliet: I noticed increased frequency of hangs specifically full screen youtube videos myself...
12:24infinity0: dmesg shows nothing like that, do i need to set some debug-levels higher or something?
12:25infinity0: thanks for the card back btw :)
13:52zoli: can you tell me if Freesync technology will be able to be used by an Nvidia card with nouveau?
14:22NanoSector: zoli: i don't think nouveau supports anything like that right now
14:47zoli: NanoSector: and can we expect it to support that in the future?
14:48zoli: because with linux most people prefer nvidia
14:48zoli: but freesync is open
14:48zoli: so the combo would be great
14:48NanoSector: zoli: I've no idea, I think the priorities are with getting the actual hardware working and then implementing all the fanciness around it :P
14:48NanoSector: but i'm not a nouveau developer
14:48zoli: g-sync is not open and there are not too many monitors with it, and they are too expensive
14:49NanoSector: i'm just that annoying dude who keeps on ranting about the issues he has
14:49zoli: haha :)
14:50zoli: NanoSector: btw do you know when will be the performance issue be solved in nouveau? I mean afaik the biggest issue was with it that it couldnt change the clock speed
14:50NanoSector: yes, reclocking is a big issue
14:50zoli: any news about it when/what can we expect?
14:51NanoSector: afaik the main problem is that nvidia doesn't release documentation and therefore nouveau devs have to kind of figure out how stuff works by themselves
14:51zoli: well, I thought that nvidia has become more open after Linux nice finger :)
14:51zoli: finger to nvidia
14:51zoli: nothing has changed?
14:52NanoSector: afaik they only really contribute to the Tegra (mobile SoC) part of nouveau but not to the desktop GPU part
14:52zoli: there was some news thereafter with more positive attitude
14:52zoli: that is sad
14:52NanoSector: very, especially since when you look at AMD they're so supportive :(
14:53zoli: yes, this is really weird, because on the otherhand althgough they are more supportive still their driver stucks
14:53zoli: and nvidia creates great closed drivers,
14:54zoli: at least one company should do both
14:54zoli: btw why do you use nouveau with nvidia?
14:55zoli: does it have any specific advantage?
14:55zoli: closed blob driver works well
14:55NanoSector: it does, I just prefer open source software
14:55zoli: so do I, but I prefer even more to have good performance
14:56NanoSector: plus on my laptop I get terrible performance either way (closed source with bumblebee, or nouveau without special software) so i just let nouveau power down my card
14:56NanoSector: to never be used again *dramatic pause*
14:57zoli: oh yes and then that optimus crap
14:57zoli: the other problem with nvidia
14:57NanoSector: it's not so much a problem anymore with stuff like PRIME in place
14:58zoli: so why dont you use prime?
14:58NanoSector: because reclocking my GPU doesn't work 100% right :x
14:59NanoSector: (PRIME only works with nouveau, and the nvidia driver always expects to be driving the entire screen so prime won't work with it right now)
15:01zoli: so it still suck?
15:02zoli: so what is the situation if I buy a laptop with intel built-in gpu plus dedicated nvidia gpu?
15:02zoli: can I use the nvidia closed driver without any issue?
15:05NanoSector: you'll need software like bumblebee to actually use your card with the proprietary driver
15:05NanoSector: with nouveau you can use it but you'll have the same reclocking issues
15:06NanoSector: (and bumblebee is a giant hack, it pretty much gives the nvidia driver a screen it so desperately wants and then copies everything back to your Intel GPU)
15:24zoli: NanoSector: but then with bumblebee nvidia hardwadr still working and consuming power?
15:25zoli: isnt the point of it, to shut it down and let only the intel gpu work?
15:26NanoSector: zoli: yes, bumblebee only activates the gpu when it's needed
15:37infinity0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848895 in case anyone could see anything interesting out of this. i also experience random freezes with various other video players
15:37infinity0: all other video players, actually
16:30imirkin: zoli: you either care about open-source of you don't. if you care about running open-source software, then nvidia blob driver is simply not an option, irrespective of the capabilities it might or might not provide.
16:31imirkin: haagch: ok. can i stick your tested-by on the patch i sent to mesa-dev? or have you not given it a run?
16:31imirkin: inglor: unlikely - this was happening in glXCreateContextAttrib or whatever - this happens before (pretty much) any other GL/GLX things to create the context.
16:33imirkin: haagch: to be clear, i'm talking about https://patchwork.freedesktop.org/patch/133190/
17:12zoli: imirkin: it is not black and white. If there is/will be a close match to the closed blob performance I will use gladly the open source one for sure
17:13zoli: I have a gtx 770 card, which was and is a very good card and cost a lot, I wont waste it to use it like a cheap crap card
17:17nyef: zoli: Heh. And here I have a different motivation: I know that my hardware can do certain things, but nouveau doesn't and the blob won't.
17:19nyef: Also, being shackled to the blob means that I can't upgrade my kernel freely, I have to wait until the blob catches up.
17:57haagch: imirkin: sure, works as expected
17:58haagch: wow, glxgears has 20 fps on the default lowest gpu pstate
18:00haagch: imirkin: wait, with vblank_mode=0 I get the all queries are busy after 8 frames, etc. message again
18:00haagch: different cause this time probably
21:12imirkin: haagch: yeah, not 100% sure what that means
22:22imirkin: zoli: that's all well and good, but either you're willing to run closed-source code in your kernel, or you're not. it's pretty black and white :)
22:35nyef: So many different black-and-white decisions to make, the overall picture is probably grayscale. (-:
22:44mwk: mupuf: nobody tried to RE the NV40 PM signals, right?
22:47zoli: imirkin: ofc I am willing to run if there is a huge performance gap
22:48zoli: nyef: you had good points with open vs blob thing
22:48zoli: I can agree on those
22:49zoli: one huge thing nouveou could do to free up my hardware that blob wont do is e.g.: Freesync
22:53nyef: Hunh. I might actually have a freesync capable monitor.
22:54nyef: ... Or not. The box doesn't seem to say anything about it.
22:55imirkin: what's the diff between the amd and nvidia things?
22:59nyef: This... conflicts with my reason for buying the hardware that I bought.
22:59nyef: It's neat, but doesn't do anything for me at this point.
23:00nyef: Hrm. Although, that said, there *is* a way that it might make sense: synchronized VBLs at a fixed rate would work quite well for me.
23:02imirkin: is there diff hw/protocol involved in freesync vs g-sync?
23:02nyef:has no idea.
23:04imirkin: as with all fringe features, this will have to wait until some interested individual with the relevant hardware investigates
23:05nyef: Sounds about right. For that matter, doesn't that apply to all features, not just the fringe ones? (-:
23:05imirkin: it does - just more people interested in non-fringe features.
23:13nyef: If I use --same-as with xrandr, does it allocate a new framebuffer and force everything to be rendered twice, or does it share framebuffer memory even if it's a separate CRTC?
23:14nyef: ... Actually, can I use --same-as if the outputs are on separate cards?
23:29pmoreau: (Hopefully I have found the last one of the errors preventing the images from building properly… It seems that 93MiB was no longer large enough for the boot partition. Let’s see if 512MiB works better.)
23:30imirkin: pmoreau: once you whack #1, then #2 gets a promotion ;)
23:30pmoreau: That’s how it works, sadly… :-/
23:31imirkin: hakzsam_: around?
23:54mupuf: mwk: nope
23:54mupuf: only uou
23:57mwk: too bad...