Re: [Nouveau] nouveau 30bpp / deep color status
On 02/05/2018 12:50 AM, Ilia Mirkin wrote: In case anyone's curious about 30bpp framebuffer support, here's the current status: Kernel: Ben and I have switched the code to using a 256-based LUT for Kepler+, and I've also written a patch to cause the addfb ioctl to use the proper format. You can pick this up at: https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!) https://patchwork.freedesktop.org/patch/202322/ With these two, you should be able to use "X -depth 30" again on any G80+ GPU to bring up a screen (as you could in kernel 4.9 and earlier). However this still has some deficiencies, some of which I've addressed: xf86-video-nouveau: DRI3 was broken, and Xv was broken. Patches available at: https://github.com/imirkin/xf86-video-nouveau/commits/master mesa: The NVIDIA hardware (pre-Kepler) can only do XBGR scanout. Further the nouveau KMS doesn't add XRGB scanout for Kepler+ (although it could). Mesa was only enabled for XRGB, so I've piped XBGR through all the same places: https://github.com/imirkin/mesa/commits/30bpp Wrt. mesa, those patches are now in master and i think we have a bit of a problem under X11+GLX: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/dri/dri_screen.c#n108 dri_fill_in_modes() defines MESA_FORMAT_R10G10B10A2_UNORM, MESA_FORMAT_R10G10B10X2_UNORM at the top inbetween the BGRX/A formats ignoring the instructions that "/* The 32-bit RGBA format must not precede the 32-bit BGRA format. * Likewise for RGBX and BGRX. Otherwise, the GLX client and the GLX * server may disagree on which format the GLXFBConfig represents, * resulting in swapped color channels." RGBA/X formats should only be exposed if (dri_loader_get_cap(screen, DRI_LOADER_CAP_RGBA_ORDERING)) and that is only the case for the Android loader. The GLX code doesn't use the red/green/blueChannelMasks for proper matching of formats, and the server doesn't even transmit those masks to the client in the case of GLX. So whatever 10 bit format comes first will win when building the assignment to GLXFBConfigs. I looked at the code and how it behaves. In practice Intel gfx works because it's a classic DRI driver with its own method of building the DRIconfig's, and it only exposes the BGR101010 formats, so no danger of mixups. AMD's gallium drivers expose both BGR and RGB ordered 10 bit formats, but due to the ordering, the matching ends up only assigning the desired BGR formats that are good for AMD hw, discarding the RGB formats. nouveau works because it only exposes the desired RGB format for the hw. But with other gallium drivers for some SoC's or future gallium drivers it is not so clear if the right thing will happen. E.g., freedreno seems to support both BGR and RGB 10 bit formats as PIPE_BIND_DISPLAY_TARGET afaics, so i don't know if by luck the right thing would happen? Afaics EGL does the right thing wrt. channelmask matching of EGLConfigs to DRIconfigs, so we could probably implement dri_loader_get_cap(screen, DRI_LOADER_CAP_RGBA_ORDERING) == TRUE for the EGL loaders. But for GLX it is not so easy or quick. I looked if i could make the servers GLX send proper channelmask attributes and Mesa parsing them, but there aren't any GLX tags defined for channel masks, and all other tags come from official GLX extension headers. I'm not sure what the proper procedure for defining new tags is? Do we have to define a new GLX extension for that and get it in the Khronos registry and then back into the server/mesa code-base? The current patches in mesa for XBGR also lack enablement pieces for EGL, Wayland and X11 compositing, but that's a different problem. -mario libdrm: For testing, I added a modetest gradient pattern split horizontally. Top half is 10bpc, bottom half is 8bpc. This is useful for seeing whether you're really getting 10bpc, or if things are getting truncated along the way. Definitely hacky, but ... wasn't intending on upstreaming it anyways: https://github.com/imirkin/drm/commit/9b8776f58448b5745675c3a7f5eb2735e3989441 - Results with the patches (tested on a GK208B and a "deep color" TV over HDMI): - modetest with a 10bpc gradient shows up smoother than an 8bpc gradient. However it's still dithered to 8bpc, not "real" 10bpc. - things generally work in X -- dri2 and dri3, xv, and obviously regular X rendering / acceleration - lots of X software can't handle 30bpp modes (mplayer hates it for xv and x11 rendering, aterm bails on shading the root pixmap, probably others) I'm also told that with DP, it should actually send the higher-bpc data over the wire. With HDMI, we're still stuck at 24bpp for now (although the hardware can do 36bpp as well). This is why my gradient result above was still dithered. Things to do - mostly nouveau specific, but probably some general infra needed too: - Figure out how to properly expose the 1024-sized LUT - Add fp16 scanout - S
Re: [Nouveau] Nouveau Digest, Vol 131, Issue 3
On 03/03/2018 12:59 AM, Ilia Mirkin wrote: On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner wrote: On 03/02/2018 11:29 PM, Ilia Mirkin wrote: OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set still only gets called with a 256-entry LUT? If so, that works nicely here, but is not intuitive :) Yes. Lots of remapping in the server, i get dizzy everytime i look at it, and forget almost immediately how stuff fits together when i don't look at it. Anyway, the final downsampling from 1024 -> 256 hw lut happens in xf86RandR12CrtcComputeGamma(), see https://cgit.freedesktop.org/xorg/xserver/commit/?id=b5f9fcd50a999a00128c0cc3f6e7d1f66182c9d5 for the latest. I'll propose that one to get cherry-picked into the server-1.19 branch as well. Hrmph. That means we should try to adjust the gamma_set helper to do the sampling when receiving a 1024-sized LUT, if people will use older X servers (seems likely). Should hopefully be straightforward, to handle just that one case. I think we never receive anything but a 256 slot LUT via gamma_set afaics? The server initializes xf86Crtc's gamma_size to 256 at startup, and none of the ddx'es ever overrides that with actual info from the kernel. What happens on older servers without that patch iff color depth 30 is selected is simply that the gamma table updates no-op, so the server runs with an identity gamma table setup at startup. Not perfect, but also not that bad, given that probably most people run their setups with a gamma of 1.0 anyway. At default depth 24 stuff works as usual. It's sending 8bpc data out to the screen, unless you're using a DP monitor (and probably would need a Kepler GPU for that anyways). I think a long time ago i tested 10 bpc output over VGA with the proprietary driver on GeForce 8800, and the current readme for the NVidia blob says it can do 10 bpc over VGA and DisplayPort, but only dithering over DVI and HDMI. I think that 10bpc HDMI support came with HDMI 1.3. Older devices (esp Tesla era) won't support that. Intuitively seems like it should Just Work (tm) over VGA. Not sure which DP version supported 10bpc+. I think i read somewhere that at least Pascal could do some deep color output over HDMI as well, which makes sense for HDMI-based HDR-10 support. I believe Kepler+ devices (and perhaps GF119 as well) should support higher bpc over HDMI. However there's no support for that in nouveau right now. I happen to have a monitor (TV) that advertises 12bpc support, so I may play with it. Here's how dithering is controlled: https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml#L435 (and also exposed in the public display class docs at http://download.nvidia.com/open-gpu-doc/Display-Class-Methods/2/ ) In theory turning off dithering should also flip off that ENABLE bit, but perhaps we messed something up. Or HDMI is extra-special and doesn't respect that bit and always has it enabled. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan
https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #53 from Ilia Mirkin --- (In reply to Lukas Wunner from comment #52) > (In reply to Ilia Mirkin from comment #49) > > (In reply to Maik Freudenberg from comment #47) > > > There's of course the possibility that some braindead vendor would ship a > > > 3D > > > class tagged device actually having outputs. > > > > This happens. A lot. > > Ilia, do you have definitive knowledge of GPUs which > a) have a different class than PCI_CLASS_DISPLAY_VGA and > b) have working DP/HDMI outputs and > c) have an integrated HDA controller? > > I'm asking because get_bound_vga() in sound/pci/hda/hda_intel.c specifically > matches against PCI_CLASS_DISPLAY_VGA only. In other words, if a GPU with > the three above-listed properties exists and is built into a hybrid graphics > laptop, it is currently not registered with vga_switcheroo, which would be > wrong. I can say with some certainty that there are laptops running around, esp GM107's, whose pci class is 3D, and that have attached DP/HDMI outputs. I don't think the users in question ever asked about audio, so I don't know about the last bit. However I can't imagine that it wouldn't be there (esp once all the proper enablement is done). Is hda_intel only for intel? If so, I'm pretty sure that all intel vga devices are PCI_CLASS_DISPLAY_VGA. However if it's used for everything, then it needs to deal with DISPLAY_3D as well. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan
https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #52 from Lukas Wunner --- (In reply to Ilia Mirkin from comment #49) > (In reply to Maik Freudenberg from comment #47) > > There's of course the possibility that some braindead vendor would ship a 3D > > class tagged device actually having outputs. > > This happens. A lot. Ilia, do you have definitive knowledge of GPUs which a) have a different class than PCI_CLASS_DISPLAY_VGA and b) have working DP/HDMI outputs and c) have an integrated HDA controller? I'm asking because get_bound_vga() in sound/pci/hda/hda_intel.c specifically matches against PCI_CLASS_DISPLAY_VGA only. In other words, if a GPU with the three above-listed properties exists and is built into a hybrid graphics laptop, it is currently not registered with vga_switcheroo, which would be wrong. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan
https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #51 from Lukas Wunner --- (In reply to Maik Freudenberg from comment #31) > As a sidenote: another user reported 5 Watts additional power draw when > enabling the audio function. Regardless of this being accurate it should be > taken into account to not enable it unconditionally since these are mobile > devices. On my GK107 I do not see any change in power consumption regardless whether bit 25 at config space offset 0x488 is set or cleared, which is somewhat disappointing. I also do not see a change in power consumption between PCI power state D0 and D3hot. So if it's true that enabling the HDA increases power consumption, that would seem to only apply to newer cards. Could somebody verify this: Do you see a consistent drop or increase in power consumption when enabling/disabling the HDA? setpci -s 01:00.0 0x488.l=0x000:0x200# disable setpci -s 01:00.0 0x488.l=0x200:0x200# enable Try this a couple of times and see if powertop shows a consistent difference in power consumption. (The laptop needs to run on battery for this to work, so disconnect the charger.) If you *do* see a difference, double-check whether runtime suspending the HDA to D3hot (using my above-linked switcheroo_devlink_v2 patch set) also shows a difference. You can force the HDA into D0 or let it autosuspend to D3hot like this: echo on > /sys/bus/pci/devices/:01:00.1/power/control# disable echo auto > /sys/bus/pci/devices/:01:00.1/power/control# enable If the reduction in power consumption turns out to be the same in D3hot versus disabling via bit 25, there's no point in adding D3cold support to hda_intel.c. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 75985] [NVC1] HDMI audio device only visible after rescan
https://bugs.freedesktop.org/show_bug.cgi?id=75985
--- Comment #50 from Lukas Wunner ---
(In reply to Denis Lisov from comment #45)
> (In reply to Lukas Wunner from comment #37)
> > Related to this issue, I've just posted v2 of my patch set to use a device
> > link for power management of GPU-integrated HDA controllers:
> > https://lists.freedesktop.org/archives/dri-devel/2018-March/168012.html
> >
> > It would be great if more people could test it. There's a 4.15-based branch
> > available at:
> > https://github.com/l1k/linux/commits/switcheroo_devlink_v2
>
> Tested these patches on Lenovo Thinkpad P50. Audio works, the HDA and GPU
> suspend when unused with no errors in logs and resume when needed.
> HDA unbind/bind worked with no errors, some "Too big adjustment {128,384}"
> messages in dmesg.
Thank you, this helps greatly. I'll add your Tested-by to the commits so that
you get credit for your testing efforts.
--
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
