00:02 mwk: well
00:02 mwk: point parameters seem to defy sanity
00:02 mwk: no wonder nobody REd these
00:31 mangix: skeggsb: :)
01:15 mangix: ugh fedora live cd comes with a broken kernel
01:19 mangix: skeggsb: can you backport 913b97f94478db1c93cc5a1f07fa03ee4e2d5f8b , 098ee77224bc76026e736e05407ff46c78f13d22 , and 3e8fbe3191d1fd94d4b25f72d383c4db7309ca4a ? It fixes GNOME starting (I have a GPU with 8GB RAM).
05:29 skeggsb: mangix: is that f26?
05:35 mangix: yes
05:37 skeggsb: and you applied those three on top of the f26 kernel and it worked fine?
05:38 skeggsb: mangix: https://github.com/skeggsb/linux/commit/e521c4a82ec33bc6aa480086f948c20944a6fbbf
05:38 skeggsb: give that a try for the display regression
05:39 skeggsb: i think it'll work for your case, but pre-gf119 will still be busted, so it's not finished yet
05:39 skeggsb: i don't actually think we can support pre-gf119 with the core helper
05:39 skeggsb: it depends on the final address-only transaction to drop the MOT bit
05:40 skeggsb: and the hardware doesn't have that concept until gf119 :P
05:41 skeggsb: airlied: ^^^ not sure if that's something that applies to any other hardware, if not, probably not much point teaching the helper about it ?
05:42 skeggsb: airlied: the change being: don't do the address-only transactions at all, and instead drop MOT on the last transaction of the last message
05:43 skeggsb: (if hw doesn't do address-only)
06:00 mangix: skeggsb: yeah i applied those on top of your linux-4.11 branch
06:02 mangix: i'm using nouveau as an external module
06:02 mangix: ie, not rebuilding the kernel
06:02 skeggsb: ahh, you're using my tree the way i do.. i can give you a patch for that instead if you prefer
06:03 mangix: sure
06:04 skeggsb: https://github.com/skeggsb/nouveau/commit/6d84f70e107a32e76471d54124a04705b0219392
06:05 mangix: will test shortly
06:05 skeggsb: cool, no worries
06:06 skeggsb: i don't have a display that fails, so i can't test it myself
06:06 skeggsb: i made sure that it kept working for me at least though :P
06:11 mangix: hmm i'm missing commits
06:12 mangix: fatal error: auxg94.h: No such file or directory
06:15 skeggsb: oops, my bad, one sec
06:15 skeggsb: mangix: fixed the commit
06:19 mangix: success
06:20 skeggsb: as in: it compiles, or the fix works?
06:21 mangix: it works
06:21 mangix: i'm in GNOME
06:21 skeggsb: sweet
06:21 skeggsb: thank you :)
06:22 skeggsb: i'll finish it up and do something with <gf119, and get it to airlied asap
06:22 mangix: how about the three commits i listed? I need those in order to get 3D acceleration.
06:23 mangix: or just wait for 4.12 for fedora :)
06:23 skeggsb: i've put it on my list to see if i can't get those added to 4.11-stable
06:23 mangix: sweet. thank you.
06:29 airlied: skeggsb: no idea how that works,
06:35 mangix: funny bug: http://imgur.com/a/TKN1P
11:32 rhyskidd: Would appreciate a review on my PMC.ELPG_ENABLE documentation that I'm looking to get into envytools
11:33 rhyskidd: Comes from the embedded Jetson world initially, but now seen on (all?) the Pascal cards
11:41 mupuf: thx!
11:42 rhyskidd: mupuf: Thanks for the quick review
11:43 rhyskidd: I'll fix the hyphen comment, but wanted to clarify your comment about future hw
11:43 mupuf: well, the PFIFO bitfield has been known to be re-arranged
11:43 mupuf: :s
11:43 rhyskidd: Do you mean that I should verify the PFIFO engines haven't changed on Maxwell and Pascal?
11:43 mupuf: that would be a good start (check the documentation, no need for REing)
11:44 rhyskidd: OK
11:44 mupuf: And I think the most future-proof would be to reference the PFIFO enum instead of inlining it
11:44 mupuf: makes sense?
11:45 rhyskidd: Broadly, I should be able to find the right doc for the PFIFO on Pascal
11:46 rhyskidd: Sorry, this is one of my first proper nouveau REing efforts, so bear with me :)
11:46 mupuf: :o nothing to feel sorry about!
12:28 mwk: nah, please don't share bits here
12:28 mwk: the bits are a subset of the main ENABLE bitfield
12:28 mwk: with differing variants
12:34 mupuf: mwk: oh dear, ok
12:34 mupuf: then yes
13:04 rhyskidd: mwk: that's helpful, I won't carry over the same enum then
21:19 docmax: anybody here?
21:19 docmax: devs?
21:42 Tom^: they usually respond when they get around, most of them read backlog/logs too. so ask your question and wait a while.
21:42 Tom^: oh he left >.<
21:59 imirkin_: mwk: btw - https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_point_parameters.txt
22:00 mwk: imirkin_: I know that, but it doesn't match the hw
22:00 mwk: anyhow - I think I mostly figured it out by now :)
22:00 imirkin_: ok
22:00 imirkin_: just wanted to point it out in case you didn't know.
22:01 mwk: the point size thing is the craziest thing on celsius T&L so far, FWIW
22:02 mwk: so basically it does a lot of computations
22:02 mwk: and then it extracts bits 12-18 of the floating-point representation, and uses it as the point size
22:03 mwk: it's your responsibility to set up the relevant constants so that it's always in the proper range and has the thing you want in the float's mantissa at the right positions
22:03 imirkin_: i guess it's expecting it to be in the (0.5, 1.0] range
22:04 mwk: well, not really, no
22:04 imirkin_: err ... maybe that's off. but either way, some fixed range.
22:04 imirkin_: [with a fixed exponent]
22:04 mwk: to make it work, you have to have it in [1.0, 1.125) range
22:04 mwk: or something like that
22:16 mwk: and curtains
22:26 mwk: soo... "only" color computations are left now
22:27 mwk: so much fun
22:31 mangix: note to self, never enable rasterization on chrome
22:32 mangix: this red screen thing is starting to get ridiculous
22:55 Lyude: imirkin_: btw, I just noticed no one ever pushed those updated arb_post_depth_coverage tests to piglit
22:55 imirkin_: =/
22:55 imirkin_: is there a branch?
22:56 Lyude: imirkin_: I don't believe so (was I supposed to make one?) I submitted patches for it a while back, I can resend if you need
22:56 imirkin_: nope
22:56 imirkin_: not necessarily
22:56 imirkin_: is there a patchwork series link? :)
22:56 Lyude: should be, lemme see
22:56 imirkin_:is quite lazy
22:57 Lyude: since i started doing review of a lot of patches I completely understand :P
22:57 Lyude: imirkin_: https://patchwork.freedesktop.org/series/24795/
22:57 imirkin_: thanks. will push when i get home.
22:59 imirkin_: i guess i had hoped the intel person who wrote the original test would review
22:59 imirkin_: but that hope has been dashed in the annals of time
23:00 imirkin_: the fact that the test fails on intel is a little sad
23:00 imirkin_: let me see if i can drum up some interest...
23:00 Lyude: yes it is :(
23:00 Lyude: especially since 90% of the time on that test was spent with me trying to test on intel until I realized it was broken on intel, lol
23:01 imirkin_: :(
23:01 imirkin_: delaying it to tomorrow so that they have a chance to review
23:01 Lyude: np
23:02 imirkin_: can you also re-test on intel if it's not difficult?
23:03 Lyude: imirkin_: oh that's np. i have every intel chipset other then bxt, back to ironlake :P
23:03 Lyude: should only need skl and kbl
23:03 imirkin_: skl is enough.