NVIDIA 355 Beta Linux Driver Released, Closer To Supporting Wayland/Mir

[andre30correia]

Good news for nvidia owners... I must say I am very much tempted to ditch my 6850 and the OSS drivers for a good ol'nvidia card... But if doing so, why not ditch Linux altogether, and install windows 7, then ?

Come on, Khronos, we need vulkan for a good open source API implementation on all cards.

On a side note, I am tempted to start a draft for multi-gpu implementation in open source if I have some time to spare this year. Are there some starting points I could use ?

you choose linux because the worst thing. lol

[dh04000]

They support EGL by specification. What they don't support are the platform specific extensions. Michael should probably change his wording.

Ideally, the Nvidia driver should recognize Wayland&Mir as EGL requesting platform, but not need or be required to support ANY platform specific extensions. We don't want to make EGL dependent on Wayland or Mir as a dependency or employ any fiddly platform hacks like we currently have with the relationship between the XServer and GLX/OpenGL. That would be pretty shit, IMO. We need to get away from these issues, not recreate them.

[tuke81]

Hmm, bunch of unsupported features are now supported in vdpau:

$ vdpauinfo 
display: :0   screen: 0
API version: 1
Information string: NVIDIA VDPAU Driver Shared Library  355.06  Tue Jul 28 20:55:42 PDT 2015

Video surface:

name   width height types
-------------------------------------------
420     4096  4096  NV12 YV12 
422     4096  4096  UYVY YUYV 

Decoder capabilities:

name                        level macbs width height
----------------------------------------------------
MPEG1                           0 65536  4080  4080
MPEG2_SIMPLE                    3 65536  4080  4080
MPEG2_MAIN                      3 65536  4080  4080
H264_BASELINE                  41 65536  4096  4096
H264_MAIN                      41 65536  4096  4096
H264_HIGH                      41 65536  4096  4096
VC1_SIMPLE                      1  8190  2048  2048
VC1_MAIN                        2  8190  2048  2048
VC1_ADVANCED                    4  8190  2048  2048
MPEG4_PART2_SP                  3  8192  2048  2048
MPEG4_PART2_ASP                 5  8192  2048  2048
DIVX4_QMOBILE                   0  8192  2048  2048
DIVX4_MOBILE                    0  8192  2048  2048
DIVX4_HOME_THEATER              0  8192  2048  2048
DIVX4_HD_1080P                  0  8192  2048  2048
DIVX5_QMOBILE                   0  8192  2048  2048
DIVX5_MOBILE                    0  8192  2048  2048
DIVX5_HOME_THEATER              0  8192  2048  2048
DIVX5_HD_1080P                  0  8192  2048  2048
H264_CONSTRAINED_BASELINE      41 65536  4096  4096
H264_EXTENDED                  41 65536  4096  4096
H264_PROGRESSIVE_HIGH          41 65536  4096  4096
H264_CONSTRAINED_HIGH          41 65536  4096  4096
H264_HIGH_444_PREDICTIVE       41 65536  4096  4096
HEVC_MAIN                      --- not supported ---
HEVC_MAIN_10                   --- not supported ---
HEVC_MAIN_STILL                --- not supported ---
HEVC_MAIN_12                   --- not supported ---
HEVC_MAIN_444                  --- not supported ---

Output surface:

name              width height nat types
----------------------------------------------------
B8G8R8A8         16384 16384    y  Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8 
R10G10B10A2      16384 16384    y  Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8 

Bitmap surface:

name              width height
------------------------------
B8G8R8A8         16384 16384
R8G8B8A8         16384 16384
R10G10B10A2      16384 16384
B10G10R10A2      16384 16384
A8               16384 16384

Video mixer:

feature name                    sup
------------------------------------
DEINTERLACE_TEMPORAL             y
DEINTERLACE_TEMPORAL_SPATIAL     y
INVERSE_TELECINE                 y
NOISE_REDUCTION                  y
SHARPNESS                        y
LUMA_KEY                         y
HIGH QUALITY SCALING - L1        y
HIGH QUALITY SCALING - L2        -
HIGH QUALITY SCALING - L3        -
HIGH QUALITY SCALING - L4        -
HIGH QUALITY SCALING - L5        -
HIGH QUALITY SCALING - L6        -
HIGH QUALITY SCALING - L7        -
HIGH QUALITY SCALING - L8        -
HIGH QUALITY SCALING - L9        -

parameter name                  sup      min      max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH              y         1     4096
VIDEO_SURFACE_HEIGHT             y         1     4096
CHROMA_TYPE                      y  
LAYERS                           y         0        4

attribute name                  sup      min      max
-----------------------------------------------------
BACKGROUND_COLOR                 y  
CSC_MATRIX                       y  
NOISE_REDUCTION_LEVEL            y      0.00     1.00
SHARPNESS_LEVEL                  y     -1.00     1.00
LUMA_KEY_MIN_LUMA                y  
LUMA_KEY_MAX_LUMA                y

I presume those hevc are supported only on gtx960 now

[magika]

So is EGL no longer just on 32bit and has 64bit support? If so, I wonder if the kwin EGL renderer backend will now work on NVIDIA....

I was also kind of hoping we would see some performance work on Shadow of Mordor - one can dream, I guess.

We had 64bit EGL for ages, what are talking about? And kwin works with EGL backed, you just need to compile Qt5 with GLES, not OpenGL. Can't have both, and distro maintainers do only OpenGL.

[pinguinpc]

At simple seek performance in blur seems more closer than 346 in this test

Maybe more later upload other test

[tarceri]

On a side note, I am tempted to start a draft for multi-gpu implementation in open source if I have some time to spare this year. Are there some starting points I could use ?

You mean crossfire support? You could try asking on the Mesa-dev mailing list or #dri-devel channel on irc

[gens]

Ideally, the Nvidia driver should recognize Wayland&Mir as EGL requesting platform, but not need or be required to support ANY platform specific extensions. We don't want to make EGL dependent on Wayland or Mir as a dependency or employ any fiddly platform hacks like we currently have with the relationship between the XServer and GLX/OpenGL. That would be pretty shit, IMO. We need to get away from these issues, not recreate them.

wayland needs EGL, not the other way around
EGL supports rendering into a buffer (window) via any classic mechanism, but it doesn't have to be (you can just as well use gles or gl)
EGL was made to do the whole multiple window thing

[bakgwailo]

We had 64bit EGL for ages, what are talking about? And kwin works with EGL backed, you just need to compile Qt5 with GLES, not OpenGL. Can't have both, and distro maintainers do only OpenGL.

Ugh, OK, yeah. I remember the first driver it was 32bit only, and I apparently missed the change log many versions ago that enabled it for 64bit. Installing now from the AUR to see if KWIN will work. AFIAK, EGL (at least in Arch's packages) do work on Intel at least, but never NVIDIA. From what I remember, Martin separated out the kwin binaries (around 4.8) so its not longer really a compile time option but runtime...

[justmy2cents]

On a side note, I am tempted to start a draft for multi-gpu implementation in open source if I have some time to spare this year. Are there some starting points I could use ?

abandon it, SLI/CrossFire is obsolete in next gen 3D. Vulkan/DX12 (both derived from /Mantle) allow direct GPU control over each gpu in the system.

[s_j_newbury]

Given all the references to modesetting above, has the nvidia module got a new parameter? Just curious.