01:49mooch2: hey imirkin_
01:49mooch2: i had to fork 86box into pcbox
01:49mooch2: but i'm still trying to work on nv3 emulation
01:49mooch2: just very slowly at this point
01:49mooch2: currently i'm installing gentoo onto a computer with an nv3 in it
01:49mooch2: and i'm going to write hardware tests for the various rendering functions
02:12mooch2: also, does anybody know how the svga portions of the g80 work? i kinda wanna start on g80 emulation
02:12mooch2: i don't have a physical g80 tho unfortunately
04:33rhyskidd: pmoreau: thanks for the review on my nouveau compiler warning series
07:03imirkin: i've made some updates to the bindless impl, it's on my 'cts' branch
07:03imirkin: haven't tested it beyond piglit
07:39jamm: pmoreau: Thanks for following up with that patch ^^
07:40jamm: hakzsam: waiting for your review when you get time :)
07:47mooch2: mwk: i'm getting some failures in your nv3 tests, on my nv3t
07:48mooch2: specifically, non-all ones masks for the vtx_x registers
07:48mooch2: they are either 0xfffffffb or 0xfffffff9
07:50mooch2: the ones that end in a 9 are 0x400408, 0x400424, 0x400438, 0x40043c, 0x400448, 0x40045c, and 0x400468
07:51mooch2: there are also state fails related to these, and the vtx tests failed too
10:01pmoreau: rhyskidd: You’re welcome! :-) I had a couple of patches I wanted to review, and finally went through my mailbox to do the reviewing and clean it up.
10:02pmoreau: jamm: I’ll try to review it again, once I’m done with Karol’s series.
10:25pmart: hello, my brightness controls don't work in Xfce because it prefers /sys/class/backlight/nv_backlight over intel_backlight (order is hardcoded). so how do I get rid of nv_backlight or maybe some other way to solve it?
10:32pmoreau: It seems weird to prefer the nv_backlight over the intel_backlight, as if you have both, the screen is very likely to be driven by the Intel card (unless it’s a desktop computer).
10:34pmoreau: pmart: If you manually use the intel_backlight, does the brightness change?
10:34pmart: pmoreau: yes it works perfectly from command line
10:35pmoreau: There is a kernel option to select the ACPI brightness backend (acpi_brightness=video/native/vendor), but I don’t think it’ll help you.
10:36pmart: they've made nv_backlight preffered choice
10:38pmart: pmoreau: it would probably give me yet another backlight interface (acpi_video)
10:39pmoreau: You should report a bug to them about it: nv_backlight shouldn’t be preferred over gmux_backlight for example (even though now Nouveau won’t register a backlight interface if the apple_gmux driver is loaded), and it should probably be after intel_backlight.
10:40pmoreau: acpi_video is after intel_backlight, so you should get the intel_backlight first.
10:40pmoreau: I don’t think Nouveau has an option to disable registering a backlight interface, so you would have to patch your kernel to disable it manually.
10:44pmart: pmoreau: thanks, I probably should file a bug with them then. I wonder if gnome does this right.
10:46pmoreau: pmart: Apparently, you can force it with some X config files: https://forums.gentoo.org/viewtopic-p-7368024.html
15:28imirkin: skeggsb: ping if you're around, want to talk about modesetting.
15:31imirkin: i'd like to figure out wtf changed to break C8 on nv50 in kernel 3.8 or whatever
15:32imirkin: it *seems* like only the first color is being read, i.e. everything maps down to 0
15:33imirkin: i wonder if the dma descriptor is broken or something
15:33imirkin: (it has to be something weird, coz it all works on gf119+)
16:16glennk: haven't seen a pc indexed color display this side of y2k...
17:13imirkin: glennk: gets automatically selected when there's 32MB of VRAM it seems
17:14imirkin: glennk: which in turn happens on some IGPs with the lowest stolen memory quantity
17:14imirkin: [for the console]
17:34imirkin: skeggsb: and wtf was NvEVO_VRAM, VRAM_LP, FB16, FB32 junk? how were those dma descriptors different?
17:38imirkin: i see where they're initialized, but ... yeah. not 1000% clear. did you need different dma descriptors for different tilings?
17:42imirkin: looks like VRAM_LP == linear, FB16 == 0x70 tiling, aka what's used for a lot of different 64-, 32-, and 16-bit formats, and FB32 == 0x7a which is used by mesa for PIPE_BIND_SCANOUT 32-bit surfaces.
17:43imirkin: and NvEvoVRAM vs VRAM_LP is the usage of NV50_DMA_CONF0_PART_256, whatever that is? ugh; so confusing!
17:48imirkin: ohhhh. LP = large page.
18:41imirkin: is it just me or has mplayer quality gone down the tubes recently?
18:41imirkin: it seems like it can't play anything at all anymore ... dvd images don't work, vdpau is messed up, ugh
18:49tethyis: luser question about nvboost on the new kernel (4.14)
18:52tethyis: modprobing max clocks with config=nvboost=2 doesn't seem to set the pstate to 0f (or 600MHz on my fermi card)
18:54tethyis: the sys/kernel/debug interface calls function not implemented when i try to echo it
18:57pmoreau: tethyis: Reclocking is not supported on Fermi cards; it’s supported only on Tesla (>= G94), Kepler, and 1st generation Maxwell.
18:58pmoreau: Also, just setting config=nvboost=2 won’t cause Nouveau to reclock to the highest performance level (0f). IIRC, it will cause higher cstates to be selected within a pstate.
19:01tethyis: makes sense, I could only make it reach 07
19:02pmoreau: Fermi reclocking is a WIP, but nothing upstreamed yet. But there are some development branches that exist.
19:04tethyis: any idea how stable these banches are?
19:05pmoreau: Hum, let me check in the logs
19:08imirkin: the logic works for the developer who wrote it on all his GPUs
19:09imirkin: that said, he has a highly finite quantity of GPUs
19:09imirkin: but probably a larger collection than almost anyone else involved in nouveau
19:11imirkin: i'm not aware of anyone else who's tested these yet - he just posted them a little while ago
19:11pmoreau: But no matter how large his collection is, there will always be a non-null probability of having a slightly different card or VBIOS, which makes it not work.
19:11imirkin: right. well he fuzzed VBIOS's to determine what blob does
19:12imirkin: but it's still easy to miss stuff.
19:12imirkin: but it's a great start.
19:13imirkin: he did that for kepler too and that also needed a bunch of fixups
19:13pmoreau: It definitely is
19:13pmoreau: I’ll have to try on my Fermi cards once I am home.
19:14pmoreau: I should probably give it a run on my Kepler card, as he did touch reclocking for gt2xx and some gkxxx.
19:14imirkin: well right - that tree might have broken other stuff
20:08imirkin: what's probably the cheapest GM20x+ card out there? probably GT 1030? or is there something cheaper?
20:09imirkin: (i'm looking for HDMI 2.0)
20:17glennk: do those have enough memory bandwidth at the lowest clocks to feed a 4k display?
20:26imirkin: glennk: dunno. i was hoping to work out the modesetting bits though
21:04pmoreau: imirkin: GTX 950 or 960 could probably as well. I can’t remember if they have HDMI 2.0 though.
21:04imirkin: they should.
21:04imirkin: but i looked at prices, it's all a lot more expensive than i want to pay for the privilege of RE'ing hdmi 2.0 stuff
21:05pmoreau: From looking at ebay, they were around $30-$60 while 1030 were more expensive
21:07imirkin: hm, $30 would be fine
21:07imirkin: i saw stuff in the $70 range
21:07imirkin: i'll check again
21:08imirkin: i think you're looking at the auctions that have 6 days left and no bids
21:09imirkin: the stuff that's coming up is trending towards $70 or so
21:09pmoreau: Ah, could be. I only had a quick look.
21:12imirkin: i think i figured out why 30bpp is totally busted on gf119+... we're just not filling the LUT in correctly.
21:12imirkin: i.e. we're filling every 4th value
21:12imirkin: so ... yeah. makes sense that only every 4th color displays non-black :)
21:15mooch3: imirkin, any idea why the hwtests are giving me different results every time?
21:16imirkin: "there's some randomness somewhere"
21:16imirkin: glad i could help :p
21:16imirkin: i'm guessing that they're somehow sensitive to mwk's environment. could be agp vs pci, could be a bunch of other things
21:22RSpliet: imirkin: 30bpp on GF119 isn't HDR, but just maps down to RGB888 values?
21:22imirkin: pre-GF119 yes
21:22imirkin: GF119+ it _should_ be HDR, at least ... at the LUT level
21:22imirkin: but we fill in only ever 4th color
21:23imirkin: so ... if the low bits != 0, then you get black
21:23RSpliet: What does the lut contain?
21:24RSpliet: imirkin: yes... in what kind of a format? How is it indexed?
21:24imirkin: each component is independent and only remaps itself
21:24imirkin: i think there's a CSC option for GF119+ too actually, but that's separate
21:25imirkin: on pre-GF119, it's a 256-sized table, on GF119+ it's 1024
21:25imirkin: (there's also a bunch of additional funky options on GF119+)
21:25RSpliet: ahh ok, that makes sense. and its filled based on defaults or values calculated from monitor colour information?
21:25imirkin: it's filled however you like
21:26imirkin: default is a straight ramp
21:26imirkin: but you can set it however you want
21:26imirkin: this isn't an nvidia-specific thing
21:26imirkin: every gpu has a LUT
21:26imirkin: since the dawn of time
21:27RSpliet: pmoreau: The devel-clk commits that touch uploading DRAM training patterns on kepler and tesla have been tested by me on quite a few cards. I did not observe any regressions. Were there other changes to Tesla/Kepler?
21:27RSpliet: imirkin: I knew they existed for 8-bit -> "24-bit" conversions, but not for any other situation :-)
21:28imirkin: right, so 8-bit is the "indexed palette" situation
21:28imirkin: but there's still a remapping possible for full color
21:28imirkin: this is what's used by e.g. xrandr --brightness
21:28imirkin: or xgamma
21:28imirkin: or stuff like redshift or whatever it's called
21:29imirkin: [or xcalib]
21:30RSpliet: Out of further curiousity: is this conversion done during compositing (so store converted framebuffers in VRAM), or rather during scanout (so in/beyond the line buffer)?
21:30imirkin: more generally it's a degamma -> csc -> gamma pipeline
21:31imirkin: csc allows mixing colors, while gamma/degamma stay within a single color component
21:31imirkin: (so csc could e.g. remap red to blue, but gamma can only change the value of blue based on the incoming blue value)
21:31imirkin: csc is a matrix transform
21:32RSpliet: Ah so csc is linear, gamma doesn't have to be :-)
21:32imirkin: gamma is just a map lookup
21:32imirkin: these are the gf119+ modes
21:33imirkin: no clue what anything except "hires" is
21:33RSpliet: in our case, following the Ford philosophy of "you can have any colour, as long as it's black" :-D
21:33imirkin: exactly. coz we fill in every 4th one ;)
21:33imirkin: [of course i say that as if i know for sure. i don't. but i'm *pretty* sure.
21:34imirkin: waiting for a few things to update before i go into reboot + test mode
21:34RSpliet: interpolate unity sounds like... it's bypassing the lut?
21:34imirkin: well, i didn't paste it, but you can just disable the lut too
21:35imirkin: not 100% sure why there are 257/1025 values rather than 256/1024
21:35imirkin: i think the last value has to do with what you do when the input range is wider than the lut
21:35imirkin: but ... not really sure :)
21:41glennk: at a guess if the color matrix maps to something outside the range?
21:43glennk: or if you have int16/fp16 input and its out of 0-1 range
21:43RSpliet: mmm... is the input always int? For fractions (float?) I could imagine mapping to an odd number of values can be more accurate as there is a centre.
21:46imirkin: looks like starting with 907c there's gamma stuff at the base level
21:47imirkin: [and 907c == gf119]
21:47imirkin: and for overlays too.
21:47imirkin: but not per-head i guess
21:49imirkin: and it does look like FP16 formats are supported (and have been for a while) -- and no clue how those might interact with a LUT
21:49imirkin: i'm guessing "poorly" :)
21:52imirkin: the most interesting bit is that apparently you can scanout 4x msaa surfaces directly.
21:58imirkin: oh yeah. we enable the NV907D_HEAD_SET_BASE_LUT_LO_MODE_INDEX_1025_UNITY_RANGE LUT for gf119+. no wonder. interesting result though.
22:03imirkin: of course X hard-codes gamma to 256... and looks like xf86-video-nouveau just takes it.
22:31imirkin: hakzsam: btw, this patch is probably for you to review: https://patchwork.freedesktop.org/patch/195251/
22:32pmoreau: RSpliet: Ben was saying that he probably broke gt215 and gk104