NVIDIA 358.09 Beta Prepares For DRM Mode-Setting Interface

[dungeon]

Yeah Catalyst supports EGL and GLES they added it 10 months ago in Omega driver 14.12.

Runing Debian Sid kernel 4.2.3 and xserver 1.17.2, Catalyst 15.9 works fine here

And really nVidia should made their shit together really because Catalyst has OpenCL 2.0 for a year now

[andre30correia]

Yeah Catalyst supports EGL and GLES they added it 10 months ago in Omega driver 14.12.

Runing Debian Sid kernel 4.2.3 and xserver 1.17.2, Catalyst 15.9 works fine here

And really nVidia should made their shit together really because Catalyst has OpenCL 2.0 for a year now

LOLLOL

[dungeon]

LOLLOL

Yes, 2.0 CL available since september last year on Linux - AMD Catalyst only

Since Catalyst has OpenGL 4.5 and OpenCL 2.0 since july, have EGL and GLES, etc.. who need to catch up i dunno

[pinguinpc]

This driver includes opengl 2015 extensions presents in 355.00.0x drivers

https://developer.nvidia.com/opengl-driver

OpenGL 2015 Driver Release Notes You will need any one of the following Fermi, Kepler or Maxwell based GPUs to get access to the OpenGL 2015 and OpenGL ES 3.2 functionality:

• Quadro series: Quadro M6000, Quadro K6000, Quadro K5200, Quadro K5000, Quadro K4000, Quadro K4200, Quadro K2200, Quadro K2000, Quadro K2000D, Quadro K1200, Quadro K620, Quadro K600, Quadro K420, Quadro 6000, Quadro 5000, Quadro 4000, Quadro 2000, Quadro 2000D, Quadro 600, Quadro 410
• GeForce 900 series: GeForce GTX 960, GeForce GTX 970, GeForce GTX 980, GeForce GTX 980 Ti, GeForce GTX Titan X
• GeForce 700 series: GeForce GTX TITAN Z, GeForce GTX TITAN Black, GeForce GTX TITAN, GeForce GTX 780 Ti, GeForce GTX 780, GeForce GTX 770, GeForce GTX 760, GeForce GTX 760 Ti (OEM), GeForce GTX 750 Ti, GeForce GTX 750, GeForce GTX 745, GeForce GT 740, GeForce GT 730
• GeForce 600 series: GeForce GTX 690, GeForce GTX 680, GeForce GTX 670, GeForce GTX 660 Ti, GeForce GTX 660, GeForce GTX 650 Ti BOOST, GeForce GTX 650 Ti, GeForce GTX 650, GeForce GTX 645, GeForce GT 645, GeForce GT 640, GeForce GT 630, GeForce GT 620, GeForce GT 610, GeForce 605
• GeForce 500 series: GeForce GTX 590, GeForce GTX 580, GeForce GTX 570, GeForce GTX 560 Ti, GeForce GTX 560 SE, GeForce GTX 560, GeForce GTX 555, GeForce GTX 550 Ti, GeForce GT 545, GeForce GT 530, GeForce GT 520, GeForce 510
• GeForce 400 series: GeForce GTX 480, GeForce GTX 470, GeForce GTX 465, GeForce GTX 460 SE v2, GeForce GTX 460 SE, GeForce GTX 460, GeForce GTS 450, GeForce GT 440, GeForce GT 430, GeForce GT 420, GeForce 405

These new OpenGL 2015 ARB extensions require NVIDIA GeForce 900 series or newer GPUs:

• ARB_post_depth_coverage
• ARB_fragment_shader_interlock
• ARB_texture_filter_minmax
• ARB_sample_locations
• ARB_shader_viewport_layer_array
• ARB_sparse_texture2
• ARB_sparse_texture_clamp

These new OpenGL 2015 ARB extensions require NVIDIA GeForce 700 series or newer GPUs:

• ARB_gpu_shader_int64
• ARB_shader_clock
• ARB_shader_ballot

These new OpenGL 2015 ARB extensions require NVIDIA GeForce 400 series or newer GPUs:

• ARB_ES3_2_compatibility
• ARB_parallel_shader_compile
• ARB_shader_atomic_counter_ops

The extensions below are part of OpenGL ES 3.2 core specification now, but they can still be used in contexts below OpenGL ES 3.2 as extensions on supported hardware:

• KHR_debug
• KHR_texture_compression_astc_ldr
• KHR_blend_equation_advanced
• OES_sample_shading
• OES_sample_variables
• OES_shader_image_atomic
• OES_shader_multisample_interpolation
• OES_texture_stencil8
• OES_texture_storage_multisample_2d_array
• OES_copy_image
• OES_draw_buffers_indexed
• OES_geometry_shader
• OES_gpu_shader5
• OES_primitive_bounding_box
• OES_shader_io_blocks
• OES_tessellation_shader
• OES_texture_border_clamp
• OES_texture_buffer
• OES_texture_cube_map_array
• OES_draw_elements_base_vertex
• KHR_robustness
• EXT_color_buffer_float

[sirdilznik]

Oh good another Nvidia/AMD flaming contest in here, just like every other graphics related thread. Fanboys are the freakin worst.

[Gusar]

When I go to Nvidia's download site and put in the info about my OS and card it still sends me to the 352 download link. I just figured 355 wasn't stable on Linux yet.

That's because 352 is the long-lived branch aka LTS. Always use this to see what's available: https://devtalk.nvidia.com/default/t...iver-releases/ <- you can clearly see that right now there's 352 long-lived, 355 current and 358 beta.


Edit: Important post from Aaron Plattner at the Nvidia forums here:

Just to set expectations, the new nvidia-modeset.ko kernel module does *not* implement the kernel's framebuffer console interface or the DRM-KMS API. It just centralizes and revamps the code that handles the display to pave the way for future improvements.

So basically, this is just *the beginning*. It's the groundwork to provide a KMS interface in the future, but we're not there yet. So for the person asking about plymouth, the answer is "not yet, but soon^(tm)"

[Nobu]

iow, they just stuck it in a module so it can be more easily replaced later. Makes sense.
sirdilznik More of a pissing contest, but same difference I guess.

[logistiker]

Holy Shit! Hell just froze over. I don't have to use uvesafb with v86d and klibc anymore with the proprietary drivers just to get a decent terminal resolution and there's no switch delay? Good news indeed! Now if they could just properly support optimus gpu switching so I don't have to waste power by running strictly on the nvidia GPU, that would be nice.

Correction: Hmm, I think hell is not quite frozen yet:

nvidia-modeset.ko does not provide any new user-visible
functionality or interfaces to third party applications. However,
in a later release, nvidia-modeset.ko will be used as a basis for
the modesetting interface provided by the kernel's direct rendering
manager (DRM).

So the question is it a later release of 358?