NVIDIA Outs New 334 Linux Driver With New Features, Fixes

[AnAkIn]

That's probably, because 3d acceleration is still bound to X11 like the blog says. You can run mpv with --vo=wayland and it will work, same with GDK_BACKEND=wayland and start gnome-calculator.

Indeed, gnome-calculator works. The weston window is always bugged though, it shows the latest image on the screen before launching weston as a background.

[blackout23]

Indeed, gnome-calculator works. The weston window is always bugged though, it shows the latest image on the screen before launching weston as a background.

Yes I noticed that too. It looks like it grabs random bits from your framebuffer. I'm running it weston 1.4 but when I upgrade to weston-git and wayland-git on Arch I only get a black screen and weston outputs some erros. I wanted to debug this with "git bisect" and see what commits breaks the compatability after 1.4.

[GreatEmerald]

Install it the "hard way" (I haven't bothered using the RPM's in years since the "hard way" is so damn simple to do). It usually takes a while for Stephen to update the RPM's and usually a bug report is required to be filed in Novell's bugzilla to do so.

I have it installed via the .run installer at the moment, yes, but RPMs are just so much cleaner...
And NVIDIA reads the Novell bugzilla? Huh.

[deanjo]

I have it installed via the .run installer at the moment, yes, but RPMs are just so much cleaner...
And NVIDIA reads the Novell bugzilla? Huh.

Nvidia doesn't do the packaging of the RPM's. openSUSE creates them and nVidia hosts them on their repo. (I also disagree about the RPM's being "cleaner" as the file placements are in non standard areas but we will agree to disagree on that).

Stefan Dirsch is the maintainer of the RPM's

https://build.opensuse.org/package/show/X11:Drivers:Video/nvidia-gfxG03

[gens]

With EGL and OpenGL ES support in the driver, what's missing until we can have Wayland or Mir using the proprietary nvidia driver, does anyone know?

a couple wayland specific calls i think relating to buffers

(KMS is no problem, the binary driver does it own KMS)

[_artem_]

It's probably not the only thing, but a standard interface for modesetting is needed. Weston uses KMS. Don't know what KDE and Gnome use, probably KMS too. Nvidia wants to have some sort of modesetting API in EGL. Until there's a standard, every compositor would need to explicitly target Nvidia's modesetting in addition to KMS. Not very elegant.

As I said last time when someone asked this, native Optimus support will not be possible until Nvidia finishes their vendor-neutral opengl library. This library will allow having multiple opengl stacks simultaneously. Right now this is not possible, all you have right now is putting the different stacks in non-standard locations and then playing with LD_LIBRARY_PATH or LD_PRELOAD or similar hacks. Not very elegant.

Why they don't open their complete driver sources? Is not a proprietary software or os, it's just a driver. If their brains aren't smart enough to make their hardware properly work just release the drivers' sources the community does it their own without reverse engendering the official driver. It's not a strategic object, it's not kinda atom launcher specifications it's just a video card driver

[Gusar]

Why they don't open their complete driver sources?

Even if they could (there's probably NDAs and other assorted agreements, patents and just plain 3rd party code to which Nvidia doesn't own the copyright in the way), how would that help? It's still a different opengl stack that would clash with mesa.

And having the code wouldn't help nouveau devs very much, because the nvidia driver is a big giant mess of application and game specific micro-optimizations and other assorted micro-optimizations, making it impenetrable. Saying "it's just a video card driver" is some serious underestimating of how complex today's GPUs and their drivers are.

Also this appeal to the almighty community that will suddenly appear once code and/or docs get released doesn't work nowadays anymore. For example, look at how incomplete the Ironlake driver is (the pre-gen6 section at the bottom): http://wiki.freedesktop.org/dri/I965Todo/. And that's despite a fully open source driver and full docs being available.

[blackout23]

Even if they could (there's probably NDAs and other assorted agreements, patents and just plain 3rd party code to which Nvidia doesn't own the copyright in the way), how would that help? It's still a different opengl stack that would clash with mesa.

And having the code wouldn't help nouveau devs very much, because the nvidia driver is a big giant mess of application and game specific micro-optimizations and other assorted micro-optimizations, making it impenetrable. Saying "it's just a video card driver" is some serious underestimating of how complex today's GPUs and their drivers are.

Also this appeal to the almighty community that will suddenly appear once code and/or docs get released doesn't work nowadays anymore. For example, look at how incomplete the Ironlake driver is (the pre-gen6 section at the bottom): http://wiki.freedesktop.org/dri/I965Todo/. And that's despite a fully open source driver and full docs being available.

What he said, plus GPUs are patent minefields.

[Prescience500]

I know EGL support was added to 64-bit Linux. Does that mean that EGL is now used by default or am I misunderstanding how it works?

[pinguinpc]

On my case this drivers works good with wine

support of vdpau feature set E is interesting

Courtesy Wikipedia

Feature Set E

Similar to feature set D but added support for decoding H.264 with a resolution of up to 4096 ? 4096 and MPEG-1/MPEG-2 with a resolution of up to 4080 ? 4080 pixels. GPUs with VDPAU feature set E support an enhanced error concealment mode which provides more robust error handling when decoding corrupted video streams.