NVIDIA 334.16 Beta Supports 64-bit EGL / OpenGL ES

[bridgman]

at they are making a egl driver for future works in wayland/mir, i don t see nothing from amd

Doesn't the radeon stack already support EGL ?

[liam]

So, with wayland, what is the go to 2d acceleration going to be?

I've been wondering about this for awhile, and haven't seen much written about it so I thought I'd mention it here and see if someone knows something more.

So, we are getting rid of X, that means no more xlib (obviously), but also no more xrender (which firefox wants to use to to upload images back to X).
We don't have any one dominant toolkit so we can't rely on the problem being addressed there.
Cairo seems like it has two options: image or gl for its backends. Given that there doesn't seem to be too much effort going to the gl backend I would IMAGINE that they are assuming image is the answer (according to ickle's tests image tends to be a bit faster on average so maybe this makes sense, at least for the mean time).
So, that's Cairo, but what about Qt? Or EFL?
I certainly understand why the devs decided that wayland is simply about buffers and not about specifying any particular rendering method but this seems like an unfortunate result of linux not having a single toolkit we could pass this problem to (hey cocoa!). Thus we end up with no particular acceleration api for people to target and no driver-based solutions like xrender (yes, I know it wasn't great but that was b/c it was stuck with x).

BTW, what happens with sna?

[dee.]

I've been wondering about this for awhile, and haven't seen much written about it so I thought I'd mention it here and see if someone knows something more.

So, we are getting rid of X, that means no more xlib (obviously), but also no more xrender (which firefox wants to use to to upload images back to X).
We don't have any one dominant toolkit so we can't rely on the problem being addressed there.

Why does there need to be a dominant toolkit for the problem to be addressed? Each application only uses one toolkit, so as long as the problem is solved by the toolkit they use, why should the application developers care if their toolkit is "dominant" or not?

[curaga]

It's bad because each toolkit has to reinvent the wheel known as "2d acceleration primitives in OpenGL".

[liam]

Why does there need to be a dominant toolkit for the problem to be addressed? Each application only uses one toolkit, so as long as the problem is solved by the toolkit they use, why should the application developers care if their toolkit is "dominant" or not?

You can which is why I asked what qt was going to do.
However that's duplicating work unnecessarily. Work that should be doing anyway. Windows is able to tie their toolkit to its graphics architecture, but they are a special case. Apple just takes gl and as a result don't have a comprehensive 2d acceleration solution (since quartzgl still isn't default to my knowledge). Ideally someone would introduce one or more gl extensions to address this.

[fastrizwaan]

nvidia binary with splash

KMS is also needed for a clean, graphical, flicker-free boot. NVIDIA still has large smudgy VESA characters.

Here's how you can get freedom from big text with nvidia binary and also get the splashy to work in fedora/korora 19/20

 cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
#GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root vconsole.keymap=us $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rhgb quiet nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off"
GRUB_DISABLE_RECOVERY="true"
#GRUB_GFXPAYLOAD_LINUX=text
GRUB_GFXMODE=1440x900x32
GRUB_GFXPAYLOAD_LINUX=keep
#GRUB_GFXPAYLOAD_LINUX=text

install xorg*nvidia then change GRUB_GFXMODE=1440x900x32 to your Xorg resolution say 1920x1080; and

sudo grub2-mkconfig -o /boot/grub2/grub.cfg ; #check whether you have grub-efi, and change the command accordingly.

reboot and you'll get smaller font and flicker free boot experience.

[fastrizwaan]

wayland, weston work with ?

Does Wayland+Weston work with NVIDIA 334.16 beta? I installed the beta drivers but wayland is only looking for nouveau on fedora 20; here's the output from tty "weston"

Date: 2014-02-10 IST
[00:01:11.210] weston 1.2.0
               http://wayland.freedesktop.org/
               Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.2.0
               Build:  
[00:01:11.211] OS: Linux, 3.12.10-300.fc20.x86_64, #1 SMP Thu Feb 6 22:11:48 UTC 2014, x86_64
config file "weston.ini" not found.
[00:01:11.211] Loading module '/usr/lib64/weston/drm-backend.so'
[00:01:11.217] initializing drm backend
[00:01:11.218] using /dev/dri/card0
failed to open /usr/lib64/dri/nouveau_dri.so: /usr/lib64/dri/nouveau_dri.so: undefined symbol: _glapi_tls_Dispatch
gbm: failed to open any driver (search paths /usr/lib64/dri)failed to load driver: nouveau
failed to load module: /usr/lib64/gbm/gbm_gallium_drm.so: cannot open shared object file: No such file or directory
[00:01:11.227] failed to initialize egl
[00:01:11.227] failed to drop master: Invalid argument
[00:01:11.240] fatal: failed to create compositor

[gens]

So, we are getting rid of X, that means no more xlib (obviously), but also no more xrender (which firefox wants to use to to upload images back to X).

subsurfaces + alpha channel should cover that, no ?

[Andrecorreia]

no

Does Wayland+Weston work with NVIDIA 334.16 beta? I installed the beta drivers but wayland is only looking for nouveau on fedora 20; here's the output from tty "weston"

Date: 2014-02-10 IST
[00:01:11.210] weston 1.2.0
               http://wayland.freedesktop.org/
               Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.2.0
               Build:  
[00:01:11.211] OS: Linux, 3.12.10-300.fc20.x86_64, #1 SMP Thu Feb 6 22:11:48 UTC 2014, x86_64
config file "weston.ini" not found.
[00:01:11.211] Loading module '/usr/lib64/weston/drm-backend.so'
[00:01:11.217] initializing drm backend
[00:01:11.218] using /dev/dri/card0
failed to open /usr/lib64/dri/nouveau_dri.so: /usr/lib64/dri/nouveau_dri.so: undefined symbol: _glapi_tls_Dispatch
gbm: failed to open any driver (search paths /usr/lib64/dri)failed to load driver: nouveau
failed to load module: /usr/lib64/gbm/gbm_gallium_drm.so: cannot open shared object file: No such file or directory
[00:01:11.227] failed to initialize egl
[00:01:11.227] failed to drop master: Invalid argument
[00:01:11.240] fatal: failed to create compositor

not works for wayland only for x

[GreatEmerald]

install xorg*nvidia then change GRUB_GFXMODE=1440x900x32 to your Xorg resolution say 1920x1080

Last I checked, it depends on the provided VESA modes. If there is no such suitable mode for GRUB to use, it won't be seamless.