00:04mwk: NV1 rasterizer considers XY coords to be signed 16-bit, but the framebuffer output considers them to be unsigned 12-bit
00:04mwk: so if you draw a real big primitive, it wraps every 0x1000 pixels :)
00:08mupuf: mwk: ahah
00:20mwk: so the general idea seems to be that rasterizer calculates (xstart, xend, y) triples, to be rendered by ROP as stripes
00:20mwk: sounds reasonable
00:21mwk: and shit can wrap in funny ways in Y direction, since it basically iterates over it, but not in the X direction, since that would just be clipped
00:22mwk: now it's just a matter of figuring out how rasterizer comes up with the stripes
00:22mwk: ... which is not going to be easy, since there's a fuckload of possible input combinations
00:25mwk: 3 possible orderings of the three vertices in X axis × 3 orderings in Y axis × 16³ X clip bit combinations × 16³ Y clip bit combinations
00:25mwk: er, wait, there are 6 orderings
00:25mwk: make that 5!, orderings vs clip rect bounduaries probably also matter
01:27nyef`: ... Damn. Sending that response through gmail -almost- worked.
02:44nyef`: Recent discoveries: There's a Maxwell GPU option for my current machine... And there's a GF117M option that might be compatible as well.
03:01whydoubt: nyef`: FWIW I have been working recently on HDMI 3D support on AMD RX4x0 cards.
03:03whydoubt: nyef`: I get the impression you're the guy working on it for nouveau. I didn't have any questions or anything, just wanted to say 'hey'.
03:03nyef`: whydoubt: Hello.
03:04nyef`: And, yeah, been trying to get it working for the past... two, two and a half weeks.
03:05whydoubt: I've been at it for a few weeks longer, but pretty sporadically.
03:05nyef`: How far have you gotten?
03:10whydoubt: With the exception of interleaved fp, I have gotten stereo-es2gears displaying on sbsh, tb, and fp seem to be working. I suspect that I've got some broken non-stereo modes though.
03:12whydoubt: It is also too tightly coupled with audio support.
03:12nyef`: Oh, is it one of those setups where you need to flip between the vendor infoframe for the 3d and another infoframe each field?
03:14whydoubt: It has more to do with how the pre-existing code is deciding that the sink is really HDMI.
03:15nyef`: I'm going to be somewhat amused if it turns out that, after all this poking about, I end up filing a bug on the i915 driver for something stereo-related. (-:
03:19whydoubt: :-) Oh, and that stereo-es2gears snippet I found had a bug on fp and tb that caused the eyes to be reversed. For a moment I thought it was my code, but no.
03:19nyef`: Good to know. I might've suspected my eyes, as well. d-:
03:20nyef`: Thus far, I've just been using testdisplay from intel-gpu-tools to test with, and the only thing that I've been having trouble with is frame-packing modes.
03:23nyef`: Hrm. I found a patch to add a stereo-es2gears to something, but it doesn't seem to match my copy of mesa in terms of directory structure, and I have no idea what else it could apply to.
03:24whydoubt: Yeah, I had time with frame-packing. I've all but given up on interleaved frame-packing. It's an odd beast.
03:26whydoubt: Yeah, I just got took the patch with stereo-es2gears.c and got it to build stand-alone.
03:26whydoubt:starts off with 'Yeah' too much
03:27nyef`: I probably start off with 'Okay' and 'Hrm' too much.
03:31nyef`: Did you have to do anything tricky to get basic frame-packing to work?
03:38imirkin: nyef`: you could troll the intel code to see if they do anything fancy for FP modes
03:38whydoubt: I think the main problem I had was figuring out that I needed to set a 'viewport' register to the proper height. I had been getting the screen to go into frame-packed mode and the buffer was the right size (2205 lines), but only the first 1080 were being read and they were being scaled up to 2205.
03:39imirkin: nyef`: you could also reach out to damien on irc - i think he's "damien_l", although not currently online. he'd hang out in #intel-gfx at least.
03:42nyef`: Hrm. What I've been finding is that the screen will balk at the transition, giving an "unsupported" message at best.
03:43imirkin: need to give a careful look at how the mode is set up
03:43nyef`: Yeah, probably.
03:44nyef`: But -after- I make a determination on if my panels will support the modes or not.
03:48nyef`: I found more evidence that I should have an intel GPU if I pull the MXM card in my test laptop. I might try that later this week.
03:55imirkin: nyef`: so like ... there's stuff we don't do. for example, nv50_display never writes e.g. the HEAD_SET_HDMI_CTRL method from what i can tell. this includes the VIC, which might be necessary to have.
03:57nyef`: So, essentially, I should see if I can get windows to play ball, and if it can, then dig further?
03:57imirkin: this apparently only became a thing with GK104 though - could be hdmi 4k-related
03:58imirkin: yeah. or intel. whatever - something that's not code that you wrote and have no idea if it works ;)
03:59nyef`: My current plan is to obtain a couple of mmiotrace results from the blob, if I can, for s2ram with the eDP and LVDS panels, then pull the card from my test laptop and see if it comes up with the intel gpu.
04:02imirkin: oh yeah, you still have that gpio resume problem right that you haven't sent patches for?
04:04nyef`: Right. And I haven't sent patches because I still need to compare the blob response between the eDP and LVDS panels before I make any determination as to what's going on with the presense detect.
04:05nyef`: I'm also, as of, what, yesterday?, having trouble with external DP hotplug.
04:05nyef`: So, more digging required there, too.
04:05imirkin: i wonder if the vrefresh is being configured correctly
04:06imirkin: is 1920x1080@24 with framepacking - is that 12fps or 24fps? if 24fps, then we should be setting the CRTC for 48hz, right?
04:07nyef`: It's 24fps, but they're 1920x2250 or so frames.
04:07imirkin: and is the mode set that way?
04:07imirkin: (why 2250 and not 2160?)
04:07nyef`: I'm guessing on that vertical.
04:08nyef`: It's double the given frame size, plus an extra vblank height.
04:08imirkin: have a look at nv50_display.c - e.g. the nv50_head_mode or nv50_head_view functions
04:12nyef`: Ugh. Black magic, both of them. /-:
04:13imirkin: should be instructional.
04:14nyef`: Oh, god. Why did that pop in chromium and not firefox?
04:19nyef`: It seems to me that all of this discussion basically hinges on the question of if my panels support FP or not, and that not much progress can be made until that question is answered.
11:55mooch: jfc, mwk
12:08mwk: mooch: you did want me to RE rasterization :p
12:09mooch: i know, but i'm not doing nv1 yet lmao
12:09mooch: wait, i thought you already did tho?
12:09mooch: or is this ifc and ifm?
12:14mwk: I only did some easy cases
12:15mwk: ie. primitives wholly in the clip area
12:15mwk: all the weird shit happens when a clip rect is involved
12:16mwk: and well... I'm doing NV1, since it's the easiest to mess with for a few reasons
12:16mwk: but, by all signs, NV3 and NV4 should be very similiar, if not identical
12:23mooch: fair enough
12:24sinopole: still, there is only one god, you probably know that joss is the one and only god, your daddy:P so you can either bejesuses or just use templeOS
12:26sinopole: either way i am ready to code actually, when putting jokes aside!
12:27sinopole: so the latest version then no longer uses pointers, but absolute addressing should be supported , as it to some degree was supported before, then probably GCN and alike support it too
12:31sinopole: there are two methods that are possible , i chose one that has no SSA requirements, it is simply counting the time where the first bits to the lanes arrive and masking right after and repartitioning the threads
12:34sinopole: it does that via inverted sign bits mask testing
12:38sinopole: but i head off, this is real stuff, dudes i do not mess with you
12:45sinopole: RSpliet: so i gonna start soon for coding it to radeon finally, allthough me as others do not care much too
12:46sinopole: RSpliet: but when you remember all that need additional perf. under nouveau, you detect cache misses too
12:46sinopole: and it will happen
19:21MarcinWieczorek: Hello. Could anyone tell me how to debug nouveau? It glitches and I don't know where to look for logs
19:21imirkin_: what gpu?
19:21MarcinWieczorek: GTX 750Ti
19:21imirkin_: what do you mean by "glitches"?
19:21MarcinWieczorek: I switched from nvidia drivers and it started occurring
19:22MarcinWieczorek: It shows all colors of the rainbow as lines and shapes changing rapidly
19:22imirkin_: under what circumstances, and where?
19:23MarcinWieczorek: Sometimes affects one window, sometimes my whole WM, everything starts to blink and fall apart. It still displays some parts tho
19:23imirkin_: i see
19:23imirkin_: can i guess that you're running xorg 1.17.x?
19:23imirkin_: so i *could* guess it, but i'd be wrong? :)
19:24MarcinWieczorek: It's Arch btw
19:24imirkin_: can you try using xf86-video-nouveau from git?
19:24imirkin_: otherwise you're on modesetting, which i don't trust.
19:24MarcinWieczorek: I'll try
19:24imirkin_: (you need to get it from git, otherwise it won't load for your gpu)
19:26imirkin_: ... because i haven't cut a release after adding maxwell support?
19:26MarcinWieczorek: There's a package
19:26imirkin_: great - so get that :)
19:26imirkin_: my point was that there was no released version
19:26MarcinWieczorek: I get it
19:27MarcinWieczorek: Well I think I have to edit it as it requires X-ABI-VIDEODRV_VERSION=20
19:27imirkin_: also make sure you're on a recent mesa version. although if you're using arch, it's probably fine.
19:27MarcinWieczorek: I think I got 23 atm
19:27imirkin_: yeah, i can't help you with arch stuff.
19:27MarcinWieczorek: Is it safe to bypass that check?
19:27imirkin_:knows nothing about arch
19:27MarcinWieczorek: Ever heard of X-ABI-VIDEODRV_VERSION?
19:28imirkin_: nope. presumably something to ensure things are properly built for new X servers?
19:28MarcinWieczorek: Lets bypass that
19:28imirkin_: the git code does support all ABI's, but it needs to be built against the proper X headers
19:30MarcinWieczorek: Well It's gonna be built against what I got at the moment so I guess that's even better
19:30MarcinWieczorek: what does libtool --finish do?
19:31MarcinWieczorek: Do I have to do that after the installation?
19:31imirkin_: nfc. it's part of autotools.
19:31MarcinWieczorek: Expand nfc please.
19:31imirkin_: no fucking clue :)
19:31MarcinWieczorek: oh damn
19:31imirkin_: you just run "make install"
19:31MarcinWieczorek: I did, that's cool
19:31imirkin_: nothing else is needed
19:32MarcinWieczorek: Cool, I have to remove xorg-server package now
19:32MarcinWieczorek: That doesn't sound good
19:32imirkin_: you still need that one.
19:32pmoreau: MarcinWieczorek: Should be fine to bypass the check and put 23 there
19:32MarcinWieczorek: pmoreau: I did thanks
19:32MarcinWieczorek: Someone messed up this package
19:32MarcinWieczorek: Actually that might be my fault...
19:33pmoreau: I am using this PKGBUILD for the testing ISO: https://github.com/hakzsam/archlive-nouveau/blob/master/pkg/xf86-video-nouveau-git/PKGBUILD
19:34MarcinWieczorek: It differs a little ;)
19:34pmoreau:should check, that besides compiling properly, it does run properly as well! :-D
19:35pmoreau: That was the PKGBUILD from Dec. 2014 it seems. That was some time ago…
19:35MarcinWieczorek: So I need libdrm-git which is also a broken package
19:36imirkin_: you don't need anything that's not in a released libdrm
19:36imirkin_: might need > some version, but nothing too recent.
19:36MarcinWieczorek: I'll bypass that
19:36MarcinWieczorek: Well It's arch
19:36MarcinWieczorek: I probably have it newer already
19:39MarcinWieczorek: Is xorg restart enough?
19:39MarcinWieczorek: brb then
19:39imirkin_: let's hope :)
19:40imirkin_: is the psychedelic coloring gone?
19:40MarcinWieczorek: I can't tell.
19:40imirkin_: tripping some lsd, so it's a bit hard to tell what's real and what's not?
19:41MarcinWieczorek: No, it just doesn't occurr all the time
19:41imirkin_: ah :)
19:44MarcinWieczorek: Well I'll just sit here hoping to be useful until it happens again
19:47lacesinout: imirkin: damn i need a rest anyways, i am entirely exhausted, things have gone awfully wrong for me, though i tried to me almost serious , still did some mistakes in my description
19:52lacesinout: i have a version that should work though, refined one, but i am entirely feeling not good at the moment at least
19:58lacesinout: will perhaps try to do it bit by bit at some stage, currently out of steam, and maybe i should at least try to recover a bit and try to fix my own issues for a while, though i think generally i have solutions to some of the issues
20:12nyef`: ... What expression would have been used instead of "out of steam" prior to 1712?
20:16lacesinout: well i dunno should even translate, i thought steam was like a smoke, like those we call aurumasin, something that works on a steam, ships and all sorts mchines
20:16lacesinout: maybe it was aroun that time when they built something like this
20:17nyef`: Exactly: 1712 was the year given for one of the earliest steam engines.
20:17nyef`: Pre-James Watt, even.
20:38lacesinout: i am not sure if and what register they use on NVIDIA, but at least amd compute has v2 register which is writable per-wave reg, it's meant to store the thread-id, i think it can use absolute address also, memory operations allow such thing clamping which is explained in the docs
20:39lacesinout: that has an effect that, when clamping is enabled all above zero, when positive result is got from read-out from the thread or maybe i use lane incorrectly, as it is with fast instructions, then clamping skips that range of instructions
20:45lacesinout: but for instance when there is a cache miss, the lane should be empty and probably forward zero instead, in that case it goes through the shuffle functions
20:46mwk: thank you.
20:46mwk: any chance of some extra ops?
20:47mwk: I'm getting quite tired of that
20:47imirkin_: i don't have access to modify the chanserv list, only skeggsb and marcheu can
20:48mwk: right... oh well, until the next reboot.
21:13MarcinWieczorek: imirkin_: Everything good so far
21:14imirkin_: MarcinWieczorek: cool!
21:21MarcinWieczorek: Thank you for your help. I'll try to reach the maintainer of nouveau-git in AUR so he fixes the package.
21:29jasonkinner: heh this idiot from poland, a purest abortion leftover along with imirkin, has managed to make #asm invite only, you are a mofo monkey, you are clueless dude
21:29imirkin_: mwk: i tend to do a whois on the ip, and ban the whole provider.
21:30mwk: sounds like a good plan, and also a lot of work...
21:30imirkin_: inetnum: 184.108.40.206 - 220.127.116.11
21:31mwk: I mean, with all the IRC gateways around
21:31imirkin_: so i'd just block the /24 or /28
21:31imirkin_: since that's easy by just replacing the last 1 or 2 with a ?
21:44imirkin_: mwk: the ip address is not of the gateway
21:44imirkin_: mwk: the ip address is of the end user
21:44imirkin_: (which could be a bouncer)
22:12MarcinWieczorek: Who's the idiot from Poland?
22:13mwk: that'd be me
22:13mwk: I just banned two of him on ##asm, since he apparently decided to bring the party there
22:13MarcinWieczorek: I'd do a whois on you if I knew how
22:14imirkin_: here's a hint - his first name might be very similar to yours.
22:14MarcinWieczorek: Marcin Kościelnicki
22:15MarcinWieczorek: Are you able to say his last name imirkin_? :D
22:15imirkin_: something like 50% of the people ever involved in nouveau have the name Martin or one of its many derivatives
22:15imirkin_: i'm definitely able to say it, but i have no idea if i'd be saying it the same way he'd say it
22:16imirkin_: i never remember what the pronounciations are for the various latin-written slavic languages. they all have funky rules, which variously contradict each other
22:17naptastic_: So, I've got a GeForce GTX 1080 (GP104)
22:17naptastic_: running Linux 4.9 with Con Kolivas' patches
22:17naptastic_: and while the mouse does work, the cursor doesn't move.
22:18naptastic_: Otherwise, everything's golden.
22:18naptastic_: AFAICT anyway.
22:18imirkin_: naptastic_: 4.10 should fix it
22:18naptastic_:is not scared of -rc1
22:18skeggsb: grab 4.10, i apparently fucked up and didn't even try moving the mouse cursor when i pushed the original gp102/4 support
22:19imirkin_: there's like a rc2 or 3 now
22:19skeggsb: 4 even :)
22:19naptastic_: kernel.org is showing -rc1 as the latest, but that's just on the front page
22:19skeggsb: * [new tag] v4.10-rc4 -> v4.10-rc4
22:19imirkin_: naptastic_: try refreshing...
22:19imirkin_: www.kernel.org shows 4.10-rc4 for me
22:20naptastic_: that browser cache, though
22:20MarcinWieczorek: why am I using 4.8.13?
22:20imirkin_: MarcinWieczorek: because you do what your distro overlords tell you to?
22:20MarcinWieczorek: But it's arch
22:21MarcinWieczorek: 4.9.4 is in testing repository
22:21naptastic_: imirkin, skeggsb, I'll have an answer in maybe half an hour (maybe less).
22:21MarcinWieczorek: Should I get it for the sake of nouveau?
22:21imirkin_: MarcinWieczorek: if you want to get good perf out of your board, you also want 4.10-rc -- that includes reclocking for your chip
22:21imirkin_: [manual, but better than none]
22:22skeggsb: naptastic_: i'm pretty confident it'll solve the cursor issue, nvidia just shuffles some regs around for the fun of it
22:22MarcinWieczorek: I wouldn't have bought a GPU if I knew I would end up on arch with i3 and vim
22:22naptastic_: yeah, if I were that much of an asshole, I'd do the same thing, just to screw with y'all
22:22imirkin_: MarcinWieczorek: would have stuck to serial port + vt100?
22:23mangix: imirkin_: why don't you trust modesetting again?
22:23naptastic_: phooey, Con doesn't have patches for 4.10 yet :( I wonder if the 4.9 patches will apply...
22:23MarcinWieczorek: I can still buy a nice lcd display on ebay... 2x16 characters
22:23skeggsb: mangix: because it dares to use the 3d driver? ;)
22:23imirkin_: mangix: coz i know how much the GL Driver sucks
22:23orbea: skeggsb: were you ever able to reproduce the issue where there is no vsync (as seen in glxgears). For me it happens after pm-suspend.
22:23imirkin_: mangix: and the nouveau ddx is super-simple and handles failure really well
22:24MarcinWieczorek: imirkin_: would it help if I got the newest kernel and came back here when it breaks or do you have enough such people here?
22:24imirkin_: [compared to the GL driver... not *well*, just ... much better.]
22:24skeggsb: orbea: i haven't tried that particular issue yet, i will on monday
22:24orbea: okay, thanks :)
22:24imirkin_: MarcinWieczorek: sorry, not sure what you're asking. can you rephrase?
22:24skeggsb: imirkin_: i don't think the ddx handles failure at all either tbh
22:24imirkin_: skeggsb: if a pushbuf fails to submit, that's handled
22:25imirkin_: skeggsb: but yeah - i won't try to suggest it's somehow perfect ;)
22:25nyef`: ... rebellious pushbufs?
22:25MarcinWieczorek: imirkin_: I want to help with tests
22:25imirkin_: great :)
22:25mangix: i'm not too familiar with the nouveau DDX( i'm on maxwell, probably unsupported ) but my experience with the ati, amdgpu, and intel DDX drivers has been horrible. tears in everything ( no proper vsync i guess ) and no real performance benefit in games.
22:25skeggsb: imirkin_: i should finish that mesa series... i side-tracked myself on kernel-side recovery stuff...
22:25MarcinWieczorek: Is 4.10 kernel a good way to help you?
22:26imirkin_: mangix: tearing is like 5 steps ahead of any issues i'm thinking of :)
22:26imirkin_: mangix: also there's support for maxwell now if you grab the ddx from git
22:26mangix: which begs the question, any performance improvement? :)
22:27imirkin_: MarcinWieczorek: mmmm ... it's not a BAD way, to e.g. test out reclocking. although at this point, we're pretty sure it's good [reclocking, that is]
22:27imirkin_: mangix: dunno. i'm most interested in "works" and "doesn't crash as often"
22:27orbea: i cant say i ever had a problem with reclocking ever since using karol's branch
22:27imirkin_: well, he has a diff gpu
22:28mangix: oh. i can't say i've managed to get X to crash. Wayland many times though
22:28hakzsam: imirkin_: maxwell1 has pretty decent perf now :)
22:28imirkin_: mangix: the average game's uptime is ... 3 hours. X uptime is ... 3 months.
22:28imirkin_: a lot of stuff can happen to a system in 3 months.
22:28imirkin_: nouveau ddx has been rock solid for me.
22:29imirkin_: oom, etc
22:29MarcinWieczorek: I don't have time for playing with the GPU. All I can do is leave feedback. I can use unstable software, that doesn't matter but I hoped that it would help
22:30imirkin_: MarcinWieczorek: well, definitely let us know when you run into issues
22:30imirkin_: esp if you can figure out how to reproduce them
22:30MarcinWieczorek: Lets start with nouveau from git, ok? I'd love to help
22:30mangix: i don't keep my system on 24/7
22:30mangix: maybe that's why
22:32imirkin_: there have also been a number of instances of GLAMOR misrendering on nouveau
22:32imirkin_: now - i'm sure that this is all issues in the nouveau GL driver
22:32imirkin_: but i have never been able to solve any of them
22:32mangix: the one in mesa?
22:33imirkin_: the really bad ones from xorg 1.17 magically went away due to some changes in GLAMOR itself
22:33imirkin_: but i can still repro the original issues by replaying apitraces
22:57orbea: imirkin_: any chance you could take a look at that openmw crash? I think it might actually be nouveau rather than mesa because it only happens with the nouveau ddx + DRI3, no crash with modesetting + DRI3, DRI2 or the llvmpipe. If not, no worries, but here is a backtrace: http://pastebin.com/HMdv4iWb apitrace: http://ks392457.kimsufi.com/orbea/stuff/trace/openmw_nouveau_dri3.trace.xz and the crash output
22:57orbea: when replaying the trace. http://pastebin.com/FzZVyGqW
22:58imirkin_: orbea: if you can cause a crash to happen by replaying a trace, that's definitely an issue in mesa
22:58imirkin_: orbea: iirc that particular issue was fixed, no?
22:59imirkin_: ok. then it was something very similar.
22:59imirkin_: can you file a bug against mesa core? mention you hit it on nouveau, but you should similarly be able to hit it with any gallium driver.
22:59orbea: someone worked around the crash by breaking the hardware mouse, was never merged as far I know
22:59orbea: though why does it not happen with modesetting then?
23:00orbea: i can file a bug report, but that part I Found curious
23:00imirkin_: i dunno - something odd happening. could even be timing.
23:00imirkin_: fine - for now file it against nouveau
23:01orbea: sure, can do
23:01imirkin_: i can't look at it now
23:01imirkin_: and i'll definitely forget before i get a chance to look :)
23:01orbea: no worries, been broken forever so no rush :)
23:01imirkin_: so bugs are useful to have
23:01imirkin_: orbea: if you can point at the workaround, that'd be great too
23:02imirkin_: i'd be curious how *anything* in mesa could cause the hw mouse to break
23:02orbea: i'll see if I can find the patch
23:02orbea: the person who made the patch (Forget who) was not able to reproduce the broken hardware mouse though
23:02imirkin_: i'm sure it was an unrelated issue.
23:12naptastic_: moving up to 4.10 fixed the mouse thing :) Thanks all!
23:13mwk: madness, I tell you, madness.
23:13mangix: hmmm this is interesting. anyone know what this commit does? https://github.com/skeggsb/nouveau/commit/c2f76cfd28289e45d6edce9b284c801d643ef5bc
23:39imirkin_: mangix: enables nouveau-exposed backlight on maxwell (for laptops)
23:39imirkin_: my guess is that this rarely happens
23:45mangix: now i have to wonder if that applies to me
23:45mangix: since i'm on a laptop with backlight issues
23:47orbea: imirkin_: i made an issue report, it includes the workaround which I guess was never a real fix. https://bugs.freedesktop.org/show_bug.cgi?id=99464
23:49MarcinWieczorek: Ok guys I'm going to sleep. I hope we'll talk soon. Cya
23:53imirkin_: mangix: is the nvidia gpu driving your panel?
23:55imirkin_: if not, then it won't help. if it is, then it will likely help.
23:59mangix: yes it is
23:59mangix: the integrated graphics is disabled at the hardware level ( forgot the exact details ) so I can't even turn it on