02:52karolherbst: imirkin: okay, poking the same regs on nouveau doesn't change the performance
02:53karolherbst: but I am sure when nouveau does this zcull thing right, we can expect around 0-10% more perf
03:11RSpliet: karolherbst: depends a lot on the workload of course :-)
03:12karolherbst: yeah I know
03:12karolherbst: I just enabled zcull in mesa
03:12karolherbst: and heaven is just white now
03:13RSpliet: I figured it wasn't as simple as flicking the magical zculling switch
03:13karolherbst: simple benchmark still work though
03:14RSpliet: I'm kind of curious how this early-z thing would work... since you haven't done your viewport transformation yet, right?
03:14RSpliet: I... damn it, back to MIAOW
03:15karolherbst: RSpliet: well earlyz is done earlier then all the other Z optimisations
03:15karolherbst: I think earlyz checks pixels directly or something
03:16RSpliet: early-z doesn't run *before* vertex shaders right?
03:17karolherbst: it runs before pixel shaders, that's I am sure off
03:17karolherbst: maybe even before fragment
03:17RSpliet: fragment shader == pixel shader
03:17karolherbst: ohh okay
03:17karolherbst: then before fragment
03:17karolherbst: zcull runs 100% before fragment
03:17RSpliet: yeah, that makes sense, the point is reducing fragments to process in your shaders :-)
03:18karolherbst: antichamber won't start now :/
03:18RSpliet: but you don't know the location of a vertex (or fragment for that matter) until you've done your vertex transformations, so logically I'd apply them afterwards
03:19RSpliet: the name early-z implies otherwise though :-P
03:19karolherbst: ohh right, maybe I shouldn't play with LD_LIBRARY_PATH inside steam
03:19karolherbst: RSpliet: I think eary-z means just earlier than any other z optimisation
03:19RSpliet: that would make sense :-)
03:20karolherbst: "GeForce 6 Series GPUs are able to cull nonvisible primitives before shading at a high rate and clip partially visible primitives at full speed. Previous NVIDIA products would cull nonvisible primitives at primitive-setup rates, and clip all partially visible primitives at full speed."
03:20karolherbst: that's under Early Culling/Clipping
03:20RSpliet: "before shading" :-D
03:21karolherbst: but the dev docs are a bit, well
03:21karolherbst: RSpliet: yeah well, GeForce 6000 was new then
03:21RSpliet: I know, I have one of those (well, technically a 7600, but meh)
03:21RSpliet: it does do vertex and fragment shading
03:23karolherbst: best parts: "Coarse Z/Stencil culling (also known as ZCULL) " and "Similarly, fine-grained Z/Stencil culling (also known as EarlyZ)"
03:23karolherbst: and the exampls when it doesn't drive good
03:23karolherbst: because that might tell us how it works
03:24karolherbst: "2. If the pixel shader writes depth."
03:24karolherbst: that's a good point
03:24karolherbst: that basically means: if one of the pixel shaders does that, we just disable zcull for that "area"
03:25RSpliet: yes, that makes sense
03:25karolherbst: so zcull is just a "stupid" algorithm basically
03:25karolherbst: which just eliminates the most obvious things
03:25karolherbst: at least it sounds like it
03:26RSpliet: "stupid" algorithms are often the most effective
03:28RSpliet: that depth test doesn't sound very trivial :-D
03:29karolherbst: I have no clue about gl anyway
03:29karolherbst: meh :/
03:29RSpliet: I'm learning...
03:30karolherbst: I was just thinking if I push some bs zcull commands to the gpu, some stuff should be there and some not
03:30karolherbst: and then I could play around a little
03:31RSpliet: zculling is in my lecture for tomorrow :-P
03:31karolherbst: seems like you will be the man for that
03:32RSpliet: can you download http://www.cl.cam.ac.uk/teaching/1516/CompGraph/CGIP.pdf?
03:32RSpliet: http://www.cl.cam.ac.uk/teaching/1516/CompGraph/CGIP.pdf ?
03:33karolherbst: well don't know if the second one
03:33karolherbst: still waiting
03:33RSpliet: page 42 (40) :-P
03:33RSpliet: second one is the correct link for the first one
03:33RSpliet: accidentally added a question mark, shouldn't matter though
03:33karolherbst: yeah, saw it
03:33karolherbst: my irc client is smart
03:34karolherbst: but that's about a specific culling thing, right?
03:35karolherbst: like if you look at a house and you don't see the back wall, you don't draw it
03:35RSpliet: that's one form of culling yes
03:36RSpliet: but it also explains the zbuffer :-P
03:36karolherbst: ahh okay
03:36RSpliet: slide 240 explains the problem
03:39karolherbst: yes, makes sense somehow
03:40karolherbst: maybe I should stay with the stuff I can do best: messing up the kernel
03:42karolherbst: I found the problem with fear
03:43karolherbst: prg: I think the problem is, that fear just stress bechmarks the gpu
03:43karolherbst: this even got my intel gpu into a hang state
04:24sillysausage: hmm, my workstation sort of froze suddenly. I could hear audio in the background of a video i was playing.
04:25sillysausage: The mouse came back briefly
04:25sillysausage: keyboard PS/2 stopped responding
04:25sillysausage: nouveau E[ PFIFO][0000:04:00.0] write fault at 0x000a300000 [PAGE_NOT_PRESENT] from PGRAPH/DISPATCH on channel 0x005fb74000 [systemd-logind]
04:25sillysausage: nouveau E[ PFIFO][0000:04:00.0] PGRAPH engine fault on channel 2, recovering...
04:25sillysausage: i saw this in the log file i wonder if that is an indication
04:26sillysausage: i've never debugged graphics related issues before, so i'm not sure if this sounds like it
04:26sillysausage: i'm using i3wm with compton
04:26sillysausage: all i had opened was another session of urxvt and firefox
04:31sillysausage: mm fuck, had it happened again
04:31sillysausage: nouveau E[ PFIFO][0000:04:00.0] write fault at 0x00089c0000 [PAGE_NOT_PRESENT] from PGRAPH/DISPATCH on channel 0x005fb74000 [systemd-logind]
04:31sillysausage: nouveau E[ PFIFO][0000:04:00.0] PGRAPH engine fault on channel 2, recovering...
04:31sillysausage: only way to fix it seems to be to reset my computer hmm, and no it's not a laptop
04:31sillysausage: plain old workstation with a NVIDIA 580 GTX
05:13RSpliet: sillysausage: upgrade your kernel
05:13imirkin: sillysausage: anything in the logs before that?
05:14sillysausage: nothing else no unfortunately and the kernel is 4.2.5
05:14sillysausage: which is fairly recent isn't it
05:15imirkin: yeah i'm not aware of anything in 4.3 that'd help you
05:16imirkin: i'm guessing "systemd-logind" is actually "X" and it forgets to update its process name before exec'ing?
05:17sillysausage: im just having a check
05:17sillysausage: nope nothing really there besides that
05:18sillysausage: but it happened twice and that error occurred at exactly that time
05:18sillysausage: it's an archlinux machine btw
05:19imirkin: unfortunately that error doesn't really say why it felt the need to write to that address
05:19RSpliet: imirkin: are the addresses plausible in the first place?
05:19sillysausage: yeah what i mainly came in here to ask is what to do in order to find out more
05:19sillysausage: so next time it happens
05:19sillysausage: i can get something meaningful
05:19imirkin: skeggsb: how feasible would it be to dump the pushbufs when that happens?
05:19sillysausage: and is there a document that talks about this
05:19imirkin: sillysausage: as a user, nothing you can do... debugging nouveau kinda sucks =/
05:20sillysausage: im guessing you need a special kernel?
05:20imirkin: oh, debugging as a developer sucks too, don't worry :)
05:21imirkin: RSpliet: sure, the addresses are plausible
05:26RSpliet: imirkin: hmm okay, well, I find the perfect alignment a bit curious (use-after-free on pushbuf? trying to update a barrier after free'ing the pushbuf?) but I'll leave it up to the expert :-P
05:27imirkin: RSpliet: the alignment is expected... it's probably a RT address or... something
05:27imirkin: RSpliet: otoh i have no idea what /DISPATCH is
05:27imirkin: RSpliet: render target
05:28RSpliet: ah... dispatch sounds like the warp/wavefront scheduler
05:28RSpliet: but does the slash imply a hierarchy or an "or"? :-P
05:28simonpatapon: imirkin: did you got my msg yesterday night?
05:29imirkin: simonpatapon: you wrote many messages... sounds like you got reverse prime working in the end though?
05:31simonpatapon: yes! solution was no xorg at all + xrandr --setprovideroutputsource 0 1
05:31simonpatapon: i wanted to thank you again for your help
05:32imirkin: np, glad it worked out
05:50simonpatapon: see you guys
05:50mlankhorst: tagr: do I need to do anything to enable usb 3.0 on the nouveau rootfs? seems in tegra you need to set some usb option in syslinux which I couldn't find back
06:41karolherbst: I think my mice breaks /
06:52karolherbst: imirkin: okay, running my dyn reclock stuff for a few days now and nouveau didn't crash because of that until now :)
06:54karolherbst: I only get those LB_ERRORs and FB_FLUSH_TIMEOUTs :/
06:54imirkin_: that's pretty good still
06:55karolherbst: well I need to test something with pretty unstable load :/
07:02karolherbst: ahh crap
07:03karolherbst: imirkin_: sometimes this happens: https://gist.github.com/karolherbst/8c3fe923c89b6c78cc45
07:05imirkin_: that sounds unfortunate.
07:05imirkin_: but i can offer little beyond sympathy :)
07:16tagr: mlankhorst: there is no support yet for USB 3.0
07:16tagr: mlankhorst: unless you're using gnurou's tree, which in turn is based on mine and might actually support it
07:17tagr: but then I'm not aware of any USB option that needs to be specifically set
07:17imirkin_: i'm guessing he means the l4t thing
07:22karolherbst: all this fun :/
07:55mlankhorst: tagr: ok
07:56mlankhorst: tagr: whats your tree? it would be worth a shot
08:00tagr: github.com/thierryreding/linux branch staging/work
08:00tagr: I rebase it all the time, so watch out for that
08:00tagr: mlankhorst: I also break things sometimes =)
09:15mlankhorst: tagr: I'm getting 10s latency now when enabling my usb webcam, cant be worse..
10:11siro: imirkin: for https://bugs.freedesktop.org/show_bug.cgi?id=93004, the apitrace file is on sarnex ftp. is it ok for you to ask him for access ?
10:11kubast2: Ok but I would had to get my whole setup on arch linux + I will have to take a shower eat dinner etc.
10:12karolherbst: kubast2: no worries
10:12karolherbst: we can do it tomorrow
10:12siro: I could upload the file somewhere else as it's to big for the bugtracker
10:12imirkin_: siro: how big is it? can you put it up on google drive? don't assume i'll be the only one looking at this
10:12karolherbst: kubast2: there are still other issue I try to track down, but some of them just happen like only when you don't wait for them to appear
10:16kubast2: I will be tomorrow then. Through can you hand me the github repos with nvidia debug tools and nouveau drm driver ,so I have everything that we will need tomorrow.
10:17siro: imirkin: 86MByte
10:18imirkin_: siro: ok, just stick it on gdrive or something
10:19kubast2: ok got the tools
10:49karolherbst: https://gist.github.com/karolherbst/22799d6be4db1732c661 :/
10:49karolherbst: this one is annoying
10:49karolherbst: I get a kworker looping there
10:50kubast2: karolherbst ,which Branch should I clone ?
10:51karolherbst: ohhh crap :/ now I know why my workaround doesn't work :(
10:51karolherbst: crappy crap
10:51karolherbst: kubast2: https://github.com/karolherbst/nouveau
10:51karolherbst: branch: master_karol_no_touchy
10:51karolherbst: of course
10:51karolherbst: when the timer value for nvkm_msec doesn't change
10:51kubast2: "/home/kubast2/nouveau/nouveau/drm/nouveau/include/nvif/os.h:34:28: fatal error: soc/tegra/fuse.h: No such file or directory"
10:52karolherbst: nouveau loops there forever
10:52karolherbst: kubast2: yeah, arch
10:52karolherbst: don't know why that only happens there
10:52karolherbst: but modify the os,h file
10:52karolherbst: and remove those tegra files
10:54karolherbst: skeggsb: we have a situation here. There are cases where nouveau turns off the card, allthough it calls timer->read later
10:55karolherbst: I don't know why that happens though
10:59karolherbst: how can I translate nouveau_pmops_runtime_suspend+0x0/0xd0 to the position inside nouveau_pmops_runtime_suspend? :/
11:01kubast2: Ok I got the openssh server set up in case something goes wrong
11:02karolherbst: kubast2: it will :D
11:03karolherbst: kubast2: do you have a 4.3 kernel?
11:03karolherbst: do you want to upgrade that?
11:03kubast2: kernel that is ,sure why not
11:04kubast2: gonna unlock testint in arch
11:08karolherbst: kubast2: okay, after you compiled and isntalled nouveau (don't forget to update initramfs and stuff), just use nouveau as usual
11:12mlankhorst: tagr: your tree doesn't select MAILBOX + XHCI mbox driver so I was getting a compiler error
11:19kubast2: So I installed 4.3 ,but it seems like x loads all avalible gpu drivers
11:25kubast2: Reverted to 4.2.5
11:26kubast2: Default make installs nouveau driver?
11:28kubast2: Ok it doesn't
11:29kubast2: Oh lovelly arch didn't installed 4.2.5 back
11:34kubast2: Well I think I'm gonna install fedora
11:34kubast2: It will be fater this way
11:40karolherbst: kubast2: mmhh?
11:40kubast2: I know what happend ,but have no idea how to solve it other than just reinstall[linux(testing) owns files of linux(not-testing) and those pacman says "nope you can't downgrade"]
11:41kubast2: X server doesn't start xD
11:41kubast2: I installed linux-4.3
11:41kubast2: +other -testing arch packages
11:41kubast2: Now x doesn't start
11:43kubast2: *nouveau-drm.c didn't compiled on 4.2.5 and i through you told me to install a newer one
11:44karolherbst: yeah, but mhhh, it shouldn't affect X though
11:45kubast2: X doesn't start because it loads nvidia ,nouveau ,nv ,vesa ,fbdev ,modsetting. But it never did threw an error about it
11:46kubast2: Most of them aren't even installed
11:46karolherbst: well you could remove nvidia
11:46karolherbst: then it should work
11:46kubast2: Well I need to install all nouveau stuff first
11:47kubast2: Change mesa ,install nouveau ,then compile your nouveau.
11:50kubast2: And to do that
11:50kubast2: I need to uninstall shit load of dependencies
11:51karolherbst: what do you hae to change about mesa?
11:51kubast2: Nvidia have it's own mesa driver
11:51kubast2: On arch
11:52karolherbst: nvidia doesn't have any mesa driver
11:52kubast2: Well in arch one gets to install mesa or mesa-nvidia
11:52karolherbst: mesa-nvidia? serisouly?
11:52pmoreau: mesa-nvidia ?!
11:52pmoreau: I don't have that one
11:52karolherbst: do you mean lib32-nvidia-libgl?
11:52kubast2: And mesa-nvidia-340xx for 340xx
11:53kubast2: it's multilib
11:53pmoreau: nvidia-libgl I agree, but not mesa-nvidia
11:53karolherbst: then nvidia
11:53karolherbst: there is no such thing as mesa-nvidia
11:53pmoreau: pacman -Ss mesa-nvidia doesn't return anything
11:53pmoreau: Or maybe you have some strange repo :-)
11:54karolherbst: I hope not
11:54karolherbst: they mess up stuff
11:54kubast2: Not mesa
11:54karolherbst: kubast2: then jsut remove the nvidia and the multilib nvidia package
11:54pmoreau: You don't need to uninstall everything
11:54karolherbst: that's all you ahve to do
11:54karolherbst: or you just change all that libgl entry stuff
11:55pmoreau: kubast2: Just run `pacman -S mesa-libgl` and confirm that you want to remove nvidia-libgl, and you should be good to go
12:01kubast2: ok got it now I'm making karols nouveau driver
12:01kubast2: the xserver runs fine
12:02kubast2: kde5 looks better on nouveau[fonts]
12:03karolherbst: kubast2: then go into /sys/kernel/debug/dri/0
12:03karolherbst: as root
12:03karolherbst: after you installed nouveau
12:03karolherbst: from my repository
12:03kubast2: gotta reboot
12:03karolherbst: nobody has any clue what is going on here? https://gist.github.com/karolherbst/22799d6be4db1732c661
12:04karolherbst: this bothers me a bit, because nouveau decides to turn off the gpu, while the gpu or the driver got into some crazy state, while a game is still running
12:05kubast2: I'm there
12:06kubast2: "DVI-D-1 HDMI-A-1 VGA-1 bufs clients gem_names name vbios.rom vm vma"
12:06karolherbst: that doesn't look like my branch
12:06kubast2: I updated mkinitcpio
12:06karolherbst: did you also copy the nouveau.ko file?
12:07karolherbst: best way is to just overwrite the already installed one inside/lib/modules/
12:07karolherbst: and rename the old one
12:08hakzsam: imirkin, no regressions with xonotic-glx and with the doom3 trace you sent me yesterday
12:08imirkin_: hakzsam: perfect
12:09hakzsam: I'm going to push and to rebase my edgeflag changes on top of it
12:10imirkin_: man these talos guys sure like to write shaders. 23M of glsl source and counting.
12:12kubast2: Tbh I have no idea where it is according to make: it's in /usr/lib/modules/4.3.0-1-ARCH/build ,but it's not really there ,and /usr/lib/modules/4.3.0-1-ARCH/build/drivers/gpu/nouveau only contains Kconfig file
12:15kubast2: definietlly not here the md5sums are the same as the module in /lib64/modules/4.3.0-1-ARCH/kernel/drivers/gpu/drm/nouveau/
12:15kubast2: and the same in /lib/(...)/nouveau
12:16kubast2: "Module.symvers and .tmp_versions" the only files that clean deleted
12:20prg_: karolherbst, wrt fear, so nothing to worry about as long as gameplay works fine, right?
12:21prg_: it's just being weird during benchmarking
12:31kubast2: DVI-D-1 HDMI-A-1 VGA-1 bufs clients cstate current_load gem_names name pstate vbios.rom vm vma
12:32kubast2: forget the modules is made in nouveau/
12:50karolherbst: prg_: well it crashed for me with gallium nine :/
12:50karolherbst: but that was inside d3dadapter.so
12:50karolherbst: kubast2: looks better now
12:51karolherbst: you could keep an eye on the last line of pstate and the content of current_load
12:51karolherbst: it should run stable for games not reaching vsync mark
12:51karolherbst: or not vsynced stuff
12:51karolherbst: but if the load fluctuate a lot it may crash the gpu
12:52karolherbst: or nouveau
12:52karolherbst: but because you don't have many states anyway, it shall not happen
12:54kubast2: Well I have checked quake3 webgl demo
12:57kubast2: I will need to run through ssh the cat commands
12:57kubast2: the gpu load is smaller when the game window isn't in focus
12:57karolherbst: ohh k
12:59kubast2: so the ssh works only for localhost
13:02kubast2: made an quick bash script
13:04kubast2: everything seems about right
13:04kubast2: core 254 pstate 0f
13:04kubast2: 1058 mhz 500 mhz
13:05karolherbst: kubast2: yeah, figures
13:05karolherbst: kubast2: the thing I am more interested in is, how does it change on loads capped by vsync
13:06karolherbst: normal desktop usage or some lightwight games, stuff like that
13:06karolherbst: you could cat pstate and current_load every second or something and log that into a file or something
13:06kubast2: I have every 5 secounds
13:06karolherbst: that's too long
13:06kubast2: but the script can be easilly modified
13:07kubast2: sleep 1
13:07karolherbst: the gpu will downclock after 3 seconds when there is no load
13:07kubast2: it doesn't downlock
13:08kubast2: it's at 0f
13:08kubast2: on idle
13:08karolherbst: then give me current_load
13:08kubast2: core:0 mem:76 video:0 pcie:0
13:08karolherbst: okay, it should downclock then
13:08karolherbst: still at 0f?
13:09karolherbst: did you put anything into pstate?
13:09karolherbst: mhh okay
13:09karolherbst: reboot with nouveau.debug=clk=trace
13:10karolherbst: I bet the 0a pstate is just too slow and my algorithm rather uses 0f
13:12kubast2: ok got it
13:16kubast2: ok so now there's none of the pstates choosed
13:17kubast2: ok so the change works now
13:17kubast2: the screen turns half black and the pstate is changed
13:18kubast2: with web browser
13:18kubast2: 07 at idle ,0a when scrolling on image heavy website
13:20kubast2: 87-152 core[firefox] 0a-07
13:21kubast2: 180+[cs:go] 0f
13:21kubast2: 0[idle= of
13:21kubast2: steam closed of core:0 mem:69 video:0 pcie:0
13:21kubast2: but still 0f
13:23kubast2: perhaps steam changes pstate manually
13:23kubast2: nah it would need root
13:24kubast2: ok launched webgl app
13:24kubast2: and then turned it off
13:24kubast2: which seems to fix the pstates
13:25kubast2: pstates work normally now
13:28karolherbst: kubast2: I need your dmesg now
13:28kubast2: 0f again
13:30karolherbst: kubast2: see those nouveau 0000:01:00.0: clk: thingies?
13:30kubast2: *actually no
13:30karolherbst: ohhh wait
13:31karolherbst: your voltage stuff fails
13:31kubast2: 0000:01:00.0: clk:
13:31kubast2: yeah now I see them
13:32kubast2: I'm guesing it's not good
13:32karolherbst: then I need your pstate file
13:34karolherbst: kubast2: ohhhhhhhh
13:34karolherbst: I have a fix for your card already
13:34karolherbst: there was another with the same issue
13:34karolherbst: that's what you need: https://github.com/karolherbst/nouveau/commit/a7c625c6be45bc790d47e58c3d403a3725fa6f43
13:35karolherbst: kubast2: okay, go to the nouveau repository
13:35karolherbst: and update the branch
13:35karolherbst: I pushed the commit on the branch
13:35kubast2: git pull
13:36kubast2: bunch of build errors
13:37karolherbst: build inside drm
13:42kubast2: ok moved module and updated mkinitcpio
13:46 < AndChat|341361> Something crashed
13:47 < AndChat|341361> The screen froozed ,when I launched quake3 webgl demo
13:48 < AndChat|341361> No reaction from ctrl+alt+f1
13:48 < AndChat|341361> Only hard reset
13:49 < AndChat|341361> After testing out nouveau with the voltage fix
13:53kubast2: The gpu and pc boots back to system just fine. Through I have school tomorrow and it's 23:00 ,so I kinda gotta go.
13:54kubast2: I will try to give you dmesg tomorrow
15:05imirkin_: skeggsb: bleh, we still get the vram config wrong?
15:05skeggsb: imirkin_: ... where?
15:05imirkin_: i thought that's what your patchw as about
15:05mark4_: do nouveau drivers work with hybrid graphics ?
15:05imirkin_: i guess it's about the number of ppc or whatever
15:05skeggsb: no, for some reason GPC5 only has 1 PPC, all the others have 2
15:05imirkin_: mark4_: http://nouveau.freedesktop.org/wiki/Optimus/ probably has the info you want
15:06imirkin_: skeggsb: weird.
15:06skeggsb: we assume all GPCs have the same number of those
15:06skeggsb: as does nvgpu
15:06skeggsb: resman, apparently, knows better
15:06imirkin_: skeggsb: any progress on parallel piglit stability? were you able to repro my fail at least?
15:07skeggsb: i haven't tried to repro yours yet
15:08mark4_: imirkin_, i read that and it has not given me a definitive answer
15:09imirkin_: mark4_: ok, then ask a definitive question :)
15:09mark4_: does nouveau work with hybrid graphics systems where there is NO mux
15:09imirkin_: define 'work'
15:09mark4_: can i get to an X desktop
15:10imirkin_: although there's no nouveau involvement required for that
15:10imirkin_: in a hybrid graphics set up your display will be attached to the IGP in all likelihood
15:10mark4_: yes there is if i want to use the nvidia card for graphics
15:10imirkin_: so you clearly have something very specific in mind for 'working'
15:11mark4_: actually the only reason to switch to nouveau from nvidia-drivers is because im not currently playing any games and do not need real 3d support
15:11imirkin_: in general it should be possible both to offload rendering via "prime" and to address remote crtc's via "reverse prime"
15:12mark4_: in that case i might as well just keep the nvidia card powered down and just use the integrated for everything
15:12imirkin_: of course various things could go wrong that will make nouveau not work for you
15:12imirkin_: yes, that's probably the best -- if you can disable it in your bios
15:12imirkin_: then it'll just be powered down and all connectors should be available via your IGP
15:13mark4_: it took 3 weeks to get X up and running with the nvidia card when i got this machine, it worked fine with the intel but that does not have real 3d support, probably even nouveau's accellerated 3d is better
15:13mark4_: but thats a non issue right now
15:14mark4_: but ty. i can try nouveau and or just the integrated :)