01:09mlankhorst: gnurou: ping?
01:09gnurou: mlankhorst: pong
01:09mlankhorst: gnurou: does the tegra support geforce tiling modes?
01:10gnurou: I'd say it should, this is supposed to be the same GPU
01:11gnurou: which mode are you thinking of? I can probably quickly check...
01:11mlankhorst: macro tiling modes
01:11mlankhorst: ones used by mesa
01:15mlankhorst: specifically for the front buffer
01:16gnurou: it definitely supports tiling (I actually have a patch for this in my WIP tree), actually buffers are passed in tiled format to the display controller
01:16mlankhorst: ah, I'm using modesetting as slave right now..
01:16gnurou: ah forget about what is in parenthesis, I was talking about something else
01:17gnurou: buffers should be rendered tiled actually, and you need to tell tegradrm that the buffer is tiled for it to be displayed correctly
01:17mlankhorst: the latter part I'm struggling with
01:18gnurou: like this: https://github.com/Gnurou/kmscube/commit/b4d79d5c4e27b6d37234a137bdefc6ff517d6ea4
01:18gnurou: look at drm_tegra_import
01:19mlankhorst: ah nice
01:19mlankhorst: I was hitting a hard lock up when starting xserver :/
01:20mlankhorst: no reply on ping any more..
01:21gnurou: format should have nothing to do with that... you would just have garbage on the screen
01:22mlankhorst: I know
01:22mlankhorst: I was also hitting a crash with mesa when starting compiz, but gpu screens are a bit harder to configure
01:25mlankhorst: have to start Xorg with -noreset, either have a xserver with autobind patch or call xrandr --setprovideroutputsource modesetting nouveau, xrandr --auto to configure, then do what you normally do
01:26mlankhorst: noreset is important or those calls will be noops
04:10mlankhorst: imirkin_: ah that was harmless, it was trying to open the tegra gpu slave and it failed. Rest worked fine..
04:19mlankhorst: so right solution was ignoring the error
07:16mlankhorst: imirkin_: ok.. present is very buggy! :P
07:18imirkin_: mlankhorst: yeah
07:18imirkin_: mlankhorst: i've just been ignoring this whole dri3 crazy tbh :)
07:19mlankhorst: I need it for tegra though..
07:19imirkin_: yeah... good luck :)
07:45mlankhorst: indeed. :/
09:04whompy: imirkin_: Steam is quite a pain with gdb it turns out. I think the backtrace will be the way to go.
09:05imirkin_: whompy: yeah, i know fairly little about it, but there are guides around
09:05imirkin_: whompy: something about DEBUGGER=gdb or something
09:05imirkin_: but even with the backtrace, i'd still want a bisect
09:06whompy: imirkin_: I tried GAME_DEBUGGER=gdb and got... something. About one line of output, nothing useful.
09:06imirkin_: (at least that's likely)
09:06whompy: yeah, figured that'd be handier.
09:18imirkin_: skeggsb: looking at your current repo, looks like nouveau_bios_posted will return true for G80+ no matter what... is that right?
09:22imirkin_: skeggsb: it looks like a nv50 check as removed in 791dc143ed2 ... if you look yesterday there was someone with 2x GM204 where the second one went bananas without the vbios being executed on it...
12:37mlankhorst: and i got visuals :o
12:37mlankhorst: afk a bit
13:50mlankhorst: gnurou: instead of discriminating on chipset for vram domain can't you use vram_size?
13:51imirkin_: it'd be nice if libdrm could just "fix" it all up
13:51imirkin_: i.e. if the dev doesn't have any vram, just s/vram/gart
13:53mlankhorst: I fixed it up in the ddx like that :P
13:53mlankhorst: except kernel does it
13:53imirkin_: even better
13:55mlankhorst: just set NOUVEAU_BO_APER for everything but allocations
14:01mlankhorst: weird, compiz works but glxinfo fails..
14:01mlankhorst: oh, no hw rendering
14:03imirkin_: that might be missing the point of the exercise
14:04mlankhorst: if present works it's still the correct excercise
14:05mlankhorst: but doesn't look like it does :(
14:24mlankhorst: $ glxgears
14:24mlankhorst: libGL error: MESA-LOADER: malformed or no PCI ID
14:24mlankhorst: MESA-LOADER: malformed or no PCI ID
14:24mlankhorst: Running synchronized to the vertical refresh. The framerate should be
14:24mlankhorst: approximately the same as the monitor refresh rate.
14:24mlankhorst: 302 frames in 5.0 seconds = 60.397 FPS
14:27imirkin_: does it actually display?
14:27imirkin_: iirc robclark sent a patch to nuke that MESA-LOADER warning
14:27imirkin_: forget what happened to it
14:28robclark: hmm, is it not on master already?
14:28robclark: (possibly I dropped the ball..)
14:28imirkin_: i sorta assumed mlankhorst was using master as his base... but you never know
14:29imirkin_: no you pushed it -- 9153dd4b7eb
14:29imirkin_: and changed that warning text so mlankhorst must have an old mesa version
14:30mmturk: hello, is gt860m maxwell supported?
14:30imirkin_: mmturk: for some definitions of 'supported'
14:30imirkin_: mmturk: er wait, what gpu is it? is it a GM108M?
14:30imirkin_: mmturk: lspci -d 10de: -nn
14:30mmturk: well 860m is listed only under kepler: http://nouveau.freedesktop.org/wiki/CodeNames/#nve0familykepler
14:30mlankhorst: I'm on 10.5 actually, easier to just grab ubuntu packaging
14:31imirkin_: mmturk: looks like GM107M according to my pci.ids file... but you never know what these marketing people come up with
14:32imirkin_: (and yeah, there's a GK104M version as well, because why not)
14:32mmturk: my nvidia chip is currently disabled from bios
14:33imirkin_: if it's a GM107 you should get modesetting support on an upstream kernel
14:33mmturk: it's a gm107, i know that
14:33imirkin_: however if you use ben's repo, he has preliminary context switching on those maxwell's
14:33imirkin_: which means that you should get full accel
14:33imirkin_: but no reclocking, so if you're expecting it to give you moar fps, you're probably in for a surprise
14:34imirkin_: although i dunno that any perf comparisons exist tbh
14:34imirkin_: ben's repo btw: http://cgit.freedesktop.org/~darktama/nouveau
14:34mlankhorst: gnurou: I'm only getting 60 fps with glxgears now :(
14:34mmturk: i don't have any performance concerns, i just want it to work
14:35mmturk: and i don't want to use prop driver
14:35imirkin_: mlankhorst: why is that bad? that's vsync'd...
14:35mlankhorst: but it's a performance regression!1one
14:36mlankhorst: and unfortunately the scanout isn't garbled, so compiz probably uses blits instead of flips
14:36imirkin_: yes... too bad
14:44mlankhorst: hm something falls back to dri2 and ruins everything for the rest :/
15:27mlankhorst: ah.. compiz uses GLES2 on arm, no wonder it didn't page flip
15:32fathercorby: When the nouveau website says kernel 3.19 can have gt series graphics card reclocking. What does that mean exactly?
15:39Karlton: fathercorby: Are you talking about "Dec, 2014: GT215/GT216/GT218 reclocking code merged into 3.19" ?
15:44Karlton: it just means those cards can be reclocked using the 3.19 kernel or newer
15:45fathercorby: Essentially i have trouble with my graphics card not working tried to upgrade to 3.19 and that caused issues booting. Running 3.16 and still same issue
15:47tobijk: fathercorby: how is that? was it ok with 3.16 before? then its not an issue with 3.19
15:48tobijk: or does it not work in general on any kernel you have tried?
15:52fathercorby: Im running debian wheezy or i was. 3.2 kernel. And now have 3.16. Still get GPU lockup
15:59tobijk: so there was and is a problem...have you reported a bug yet, or is it a already reported one?
16:02fathercorby: Havent yet. Imirkin recommended i upgrade my kernel version prior to any bug reports
16:31skeggsb: imirkin: none of the code in that particular place is necessary for nv50-, and isn't (anymore) even related to posting the board.. a lot more of that code is going away when i (finally..) managage to finish off the atomic/display work i've got going on, and eventually the only bits that will be left will be moved to dispnv04/
16:31skeggsb: i *did* see that bug though, and there's definitely something else not right
16:54imirkin_: skeggsb: ok :)
16:55imirkin_: skeggsb: it *did* start working (for some weak definition of working) with NvForcePost
16:58skeggsb: could be good to get a trace of the binary driver, try and glean what kind of check they're using to know whether devinit is necessary or not
16:58skeggsb: ... or i guess we could try asking them
16:58mjg59: skeggsb: Outside devinit, what scripts do we pull from the ROM at runtime?
16:59skeggsb: mjg59: all sorts of places, modesetting mostly, but various bits of memory controller init, on maxwell there's some stuff in the for gr init
16:59skeggsb: in there*
16:59mjg59: skeggsb: Have you noticed any kind of signatures associated with the scripts?
17:00skeggsb: no, i have not
17:00skeggsb: i didn't look too hard though
17:00imirkin_: mjg59: there are checksums, fwiw
17:01mjg59: skeggsb: I'm trying to find out from nvidia how they handle this
17:01mjg59: Because it seems kind of important in a secure boot world
17:03skeggsb: mjg59: well, starting from gm204 the devinit scripts are signed somehow.. we have to upload them to the PMU falcon now and have it executed there
17:03mjg59: skeggsb: Right, I'd heard that
17:03skeggsb: presumably, that's validated by the hardware and rejected if not correct
17:03mjg59: Is that true for modeset as well?
17:03skeggsb: no, we execute those on the cpu
17:04mjg59: skeggsb: Interesting
17:04mjg59: Does the bytecode strictly limit which registers can be hit?
17:05mjg59: Or is it possible to do basically arbitrary GPU programming with it?
17:05skeggsb: we can hit any register
17:05skeggsb: nvidia have started restricting what registers can be touched by the host though...
17:05skeggsb: hence why we're fucked and can't bring up gm204 properly now without nvidia's help..
17:06mjg59: skeggsb: Ok, sounds like it may be related
17:06skeggsb: (only a falcon in "heavy secure" mode can touch them, which requires the firmware to be signed by nvidia)
17:07mjg59: skeggsb: So for instance could a modeset script theoretically trigger arbitrary DMA?
17:07airlied: they unfortunately don't let us upload keys via the bios
17:07mjg59: (assuming no iommu)
17:07mjg59: airlied: fuckers
17:07airlied: we should send rms around
17:07mjg59: They could make it a one way trap in exitbotservices
17:08skeggsb: that would have been preferable
17:08mjg59: Depends whether they're doing it for user security or securing DMA
17:08mjg59: Securing DRM
17:08mjg59: FSF board meeting tomorrow
17:08mjg59: skeggsb: It'd be interesting to do some research into whether it's possible to reflash the scripts such that modeset compromises an OS
17:09skeggsb: yes, i guess it could be possible for a script to touch system memory without an iommu
17:09skeggsb: there's numerous different ways one could go about it
17:09mjg59: skeggsb: Cool
17:10mjg59: skeggsb: Want to work on a high visibility security thing at some point? :p
17:11skeggsb: mjg59: such as?
17:12mjg59: skeggsb: If root can reflash a GPU ROM such that root can trigger a modeset that lets them run arbitrary kernel code, that's a thing of interest
17:13airlied: would reflashing the gpu rom outside the box count? we could have badgpu
17:13imirkin_: mjg59: you can get the gpu to write anything on sufficiently old hw... like G84:G98 all have very insecure video decoding unit api's
17:13mjg59: airlied: Ha. Not so much, sadly.
17:14imirkin_: no root necessary
17:14mjg59: imirkin_: It's only *really* interesting if it's a system with Secure Boot
17:14mjg59: Because otherwise you have other attack methods for altering the kernel
17:14imirkin_: mjg59: you could plug such a gpu into a system with secure boot, no? i know little to nothing about secure boot
17:15skeggsb: would a system with secure boot even make sense without an iommu present.. i mean, that leaves a really big attack surface that's hard to fully close given the number of random devices present
17:16mjg59: imirkin_: You could, but nobody would ship like that - the firmware would never bring the card up
17:16mjg59: skeggsb: Unfortunately, Intel
17:16mjg59: Specifically product differentiation that means low-end CPUs don't have an iommu
17:21skeggsb: mjg59: https://github.com/envytools/envytools/blob/master/rnndb/bus/pbus.xml#L369 << that's probably the easiest route to touching arbitrary system memory
17:21skeggsb: mjg59: that register remaps the 1MiB window at BAR0+0x700000 over whatever you like
17:32skeggsb: mjg59: it's entirely possible that nvidia's script interpreter has protections that ours doesn't
18:38mjg59: skeggsb: Yeah, but it'd be interesting to find out
18:40gnurou: mlankhorst: re: vram_size, I thought about it but it seems vram_size indicates the amount of *free* vram at the moment, not the whole memory
18:41gnurou: mlankhorst: so this could lead to the (improbable) situation where desktop GPU would fall back to TTM memory instead of failing if all VRAM is used
18:41gnurou: ... which would not necessarily be a bad thing, maybe
18:41imirkin_: gnurou: really? i thought it was the quantity of (non-pinned i guess) vram
18:43gnurou: imirkin_: let me confirm that...
18:46gnurou: right, vram_available is decreased on nouveau_bo_pin
18:46imirkin_: which happens pretty rarely, no?
18:46imirkin_: like the fb is pinned
18:46imirkin_: vbios probably
18:46gnurou: yeah, and fences
18:47gnurou: anyway, it should always report non-zero for devices with VRAM, so I guess it is a reliable indicator
18:47imirkin_: unless you're trying to run a 4k screen off an 8MB Diamond Viper (NV04)
18:48imirkin_: seems ok to use GART in that case though ;)
18:48gnurou: yeah, I guess your biggest problem will not be the amount of VRAM available in that scenario :)
18:49imirkin_: the TNT2 i have didn't want to do 1920x1200 over VGA :(
18:49gnurou: good then, I will resend the Mesa series using this
18:49imirkin_: it was able to do 1680x1050 though
18:49gnurou:wants to reach closure on gk20a
18:50gnurou: (at least the *feeling* of closure)
18:52gnurou: mmm actually if we rely on vram_size, couldn't we have libdrm do the substitution transparently...
18:53gnurou: ah but then Mesa would believe the buffer is in VRAM and base its logic on this assumption
18:53imirkin_: iiuc, mlankhorst hacked the kernel to do the substitution
18:54gnurou: even better - but also dangerous maybe, for the reason I just gave
18:54imirkin_: yeah... but mesa _mostly_ doesn't care
18:55imirkin_: oh, except the buffer transfer stuff won't be as efficient as it could be
18:55imirkin_: ideally the bo's binding would reflect its actual state
18:56gnurou: mlankhorst: do we plan to upstream that in-kernel buffer location substitution?
18:58imirkin_: i think he has X mostly working on tegra
19:04imirkin_: gnurou: btw, for the tegra x1, do you guys plan on fixing up mesa for maxwell, or is that left to the reader? it mostly works but there are a few issues...
19:08gnurou: imirkin_: what are the issues with Mesa?
19:09imirkin_: just some rendering bugs. the "flush vertex buffers" method either went away or got moved, i bet that's a part of it
19:09gnurou: actually I have started bringing up x1's GPU with Nouveau, so I may hit these issues later and maybe fix them
19:09imirkin_: xonotic triggers them apparently
19:09gnurou: still in the kernel though, because it is GM2 :/
19:10imirkin_: oh, joy!
19:10imirkin_: well there's pretty basic GM20x support in there now as you probably saw... but nothing that works with the secure thing
19:11gnurou: yeah, so no GR at all, which is what I am interested in :)
19:11imirkin_: right :)
19:11gnurou: well, it's easy to find out who is to blame for this situation
19:11gnurou:looks at his badge
19:11imirkin_: if you have access to the 3d class docs, could you see if there's some sort of vertex buffer flush method?
19:12imirkin_: it was method 0x142c on fermi/kepler
19:12gnurou: the class is MAXWELL_A (0xb097), right?
19:13gnurou: I'm terrible at looking at the class docs... mostly because I spent my time on the kernel side of things
19:13imirkin_: well, find the kepler docs
19:13imirkin_: and look up 0x142c
19:13imirkin_: and look for a similar name in the maxwell docs
19:15gnurou: I don't even know why these things are called "methods"
19:15imirkin_: because they call methods in the gpu
19:15gnurou: yeah but in practice they are just register offsets, right
19:15imirkin_: it's best to model them as function calls which take a value
19:16imirkin_: sure, but writing to the register might cause it to do funny things
19:16imirkin_: it's not just a "stored value"
19:16imirkin_: although a lot of them are
19:16imirkin_: but among other things, many methods check the values and throw errors if they dislike the values
19:17imirkin_: although sometimes you only get the errors later when you try to draw
19:17imirkin_: and it's like "no, i dislike your parameters, try again"
19:17imirkin_: the other thing is that in some cases, like data upload, you keep writing values to the same method
19:18imirkin_: (like constbuf uploads)
19:18gnurou: one thing I'm curious to know is how you can know all these details without being connected to NVIDIA whatsoever :)
19:18imirkin_: reading the mesa driver's code is quite helpful
19:18gnurou: I don't remember the envytools doc mentioning all this
19:18imirkin_: and there are a lot of docs in envytools
19:19imirkin_: envytools documents the pushbuf format
19:19imirkin_: and the things it can do
19:19imirkin_: i bet the nv04 format came from the 'nv' driver, and given that knowledge working out the nvc0 stuff wasn't a HUGE leap
19:20imirkin_: since it's not *such* a huge change (although still quite different, i bet it took a lot of time)
19:20imirkin_: and then you stare at a lot of driver traces and try running stuff and see what happens
19:21gnurou: uh, that's interesting - 0x142c just vanished in Maxwell, and I cannot find anything similar by name... :/
19:21imirkin_: i wonder if it was connected to the vertex quarantine or whatever thing
19:21imirkin_: and didn't actually flush vbo's on fermi/kepler either
19:23gnurou: I'm afraid I cannot talk too much about this :/
19:23imirkin_: was 0x142c associated with functions of 0x17bc/0x17c0?
19:23gnurou: have you tried asking on the mailing list we opened for that purpose?
19:23imirkin_: no, i probably should
19:23imirkin_: i should probably just look at traces and work it out
19:24imirkin_: i don't have a maxwell card though, and doing this sort of thing remotely is tricky when the repro is 'run xonotic'
19:25gnurou: well once I finally manage to get GR to render stuff, I might have a look at it myself
19:26gnurou: but the ML is definitely the best place to ask this kind of thing - since the question is simple, you will probably get an immediate answer
19:26fathercorby: Is there a way to send a log when all i can do is get to the command line?
19:27imirkin_: fathercorby: dmesg
19:28fathercorby: Right but it gives me limited scrolling so i cant see the whole log
19:28imirkin_: gnurou: dunno, response rate/speed on those questions is... questionable.
19:28imirkin_: fathercorby: dmesg > foo.log
19:29imirkin_: gnurou: i use it as a last-ditch place to dump questions that i don't plan on being able to come up with answers to on my own
19:29imirkin_: since the tendency is not to receive answers in the first place
19:30imirkin_: although i was very surprised that someone took my vp3 questions seriously (even though in the end i did end up working it out myself)
19:31gnurou: still, it's definitely a better resource than myself for this kind of questions :P
19:31imirkin_: fair enough :)
19:31imirkin_: didn't mean to put you in an awkward position, really appreciate you guys working on nouveau :)
19:31gnurou: I lack both the knowledge and the permission to answer these :/
19:32gnurou: nothing awkward, actually we should be able to discuss these issues in the open
19:33gnurou: guess we are still trying to find our style - hopefully communication will improve further
19:33imirkin_: well, i'll send a quick question, let's see what happens
19:33imirkin_: imho it'd be best to have a bugtracker-style approach... right now it feels like sending things to a blackhole
19:34imirkin_: maybe i'll get an answer 30 minutes later, or 30 days later, or never
19:34imirkin_: all 3 of those have happened
19:34gnurou: I can tell you that they don't end up in /dev/null, promised
19:34imirkin_: oh i know they go to actual people
19:34imirkin_: but i also know what happens to emails once they scroll off the inbox list :)
19:35gnurou: it's like patches... you should not be shy to post a [RESEND]
19:35gnurou: seriously, just insist until you get an answer
19:35gnurou: it's good for us too to be under pressure to provide this information
19:38fathercorby: Where should i send the log?
19:39imirkin_: gnurou: ok, sent. let's find out which situation this is...
19:39imirkin_: fathercorby: pastebin it
19:44imirkin_: fathercorby: you have the ill-fated GT215 with GDDR5, i'm afraid
19:44fathercorby: Ie no fix yet?
19:44imirkin_: fathercorby: more recent kernels should have better support for it, but it's still not quite perfect
19:45imirkin_: kernels without the fix get an instant GPU lockup message as you see with 3.16
19:45imirkin_: kernels with the fix should kinda-sorta work, but you'll see a bunch of artifacts
19:45imirkin_: you are the proud owner of one of the *very* few card types that don't work at all with nouveau
19:46imirkin_: (in fact that might be the only one where the whole category has just never worked)
19:46fathercorby: Im so proud.... only me...
19:46imirkin_: well, i actually have one too :)
19:46fathercorby: Oh lol.
19:46imirkin_: but was unable to come up with the original fix, and now it's sitting on my shelf
19:46imirkin_: skeggsb worked out a fix for the insta-lockup problem
19:46imirkin_: but other issues remain
19:47fathercorby: Whats the overall issue?
19:47fathercorby: I mean anything you say will be over my head
19:47imirkin_: fathercorby: looks like 3.18+ should have the initial fix
19:47imirkin_: the overall issue is that it doesn't work :)
19:48fathercorby: I see so at this point i just need to nomodeset
19:49imirkin_: fathercorby: you can use noaccel=1 which should still let you use higher resolutions
19:51fathercorby: So where do i do that exactly?
19:51imirkin_: fathercorby: same place you do nomodeset... just instead add nouveau.noaccel=1
19:52fathercorby: Ok i guess the nvidia proprietary dont work well?
19:55fathercorby: What does noaccel=1 actually do?
19:56imirkin_: fathercorby: it disables any acceleration
19:56imirkin_: fathercorby: to answer your other question, nvidia blob driver should work just fine
20:00fathercorby: So why scrap your computer if the nvidia one works? Just a question.
20:04imirkin_: don't think anyone was suggesting that...
20:18imirkin_: gnurou: ok, i've also pinged the two other questions i've sent in and not gotten answers on
20:18imirkin_: gnurou: let's see what happens. maybe one of the three gets something :)
20:21imirkin_: gnurou: although the record isn't as bad as i had remembered... i've sent in 7 questions (not counting the new one today), 2 went totally unanswered, 1 had a non-answer "i'll look at this" and never did (and i eventually worked it out). that's still a ~50% response rate within 60 days :)
20:39gnurou: being on the other side of the mail server I can tell you the people here *really* want to give you answers. But at the same time they also have a shitton of things to do, so don't hesitate resending/pinging until you get satisfaction
20:41imirkin_: gnurou: yeah, i'm sure that the people who (can) get the answers aren't the assholes in this equation
20:41imirkin_: gnurou: that doesn't mean that it doesn't end up looking shitty from my side :)
20:42imirkin_: anyways, i sent in the new question, and pinged the 2 that didn't get any replies before
20:46gnurou: imirkin_: ossom! ^_^b
21:10imirkin_: gnurou: i'll celebrate when someone answers :)