NVIDIA 334.16 Beta Supports 64-bit EGL / OpenGL ES

[Tobu]

NVIDIA could start reimplementing basic facilities with flintstones, or they could start using what the kernel provides.
This is the reason they need a KMS driver, and it explains why their driver sucks so much at basic things.
Your points on how they could try to mix and match things they've refused to use are quite theoretical.

[johnc]

NVIDIA could start reimplementing basic facilities with flintstones, or they could start using what the kernel provides.
This is the reason they need a KMS driver, and it explains why their driver sucks so much at basic things.
Your points on how they could try to mix and match things they've refused to use are quite theoretical.

They have a KMS driver.

[pinguinpc]

On mi case this drivers works good with wine 1.7.12

[tuke81]

Hmh what egl specific extensions does wayland need? And what else does it need.

$ es2_info
EGL_VERSION = 1.4
EGL_VENDOR = NVIDIA
EGL_EXTENSIONS = EGL_NV_system_time EGL_KHR_surfaceless_context EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_config_attribs EGL_KHR_fence_sync EGL_NV_sync EGL_KHR_reusable_sync EGL_KHR_create_context EGL_EXT_create_context_robustness EGL_KHR_stream EGL_KHR_stream_fifo EGL_KHR_stream_producer_eglsurface EGL_KHR_stream_consumer_gltexture EGL_NV_stream_sync EGL_KHR_get_all_proc_addresses
EGL_CLIENT_APIS = OpenGL_ES
GL_VERSION: OpenGL ES 2.0 334.16
GL_RENDERER: GeForce GT 240/PCIe/SSE2
GL_EXTENSIONS:
    GL_EXT_blend_minmax, GL_EXT_color_buffer_float, 
    GL_EXT_color_buffer_half_float, GL_EXT_debug_label, GL_EXT_frag_depth, 
    GL_EXT_map_buffer_range, GL_EXT_occlusion_query_boolean, 
    GL_EXT_robustness, GL_EXT_separate_shader_objects, 
    GL_EXT_shader_integer_mix, GL_EXT_shadow_samplers, GL_EXT_sRGB, 
    GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_s3tc, 
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_format_BGRA8888, 
    GL_EXT_texture_sRGB_decode, GL_EXT_texture_storage, 
    GL_EXT_unpack_subimage, GL_KHR_debug, GL_NV_bgr, GL_NV_copy_buffer, 
    GL_NV_copy_image, GL_NV_draw_buffers, GL_NV_draw_instanced, 
    GL_NV_EGL_stream_consumer_external, GL_NV_explicit_attrib_location, 
    GL_NV_fbo_color_attachments, GL_NV_framebuffer_blit, 
    GL_NV_framebuffer_multisample, GL_NV_generate_mipmap_sRGB, 
    GL_NV_instanced_arrays, GL_NV_occlusion_query_samples, 
    GL_NV_non_square_matrices, GL_NV_pack_subimage, GL_NV_packed_float, 
    GL_NV_pixel_buffer_object, GL_NV_read_buffer, GL_NV_read_depth, 
    GL_NV_read_depth_stencil, GL_NV_read_stencil, GL_NV_shadow_samplers_array, 
    GL_NV_shadow_samplers_cube, GL_NV_sRGB_formats, GL_NV_texture_array, 
    GL_NV_texture_border_clamp, GL_NV_texture_compression_latc, 
    GL_NV_texture_compression_s3tc, GL_NV_texture_compression_s3tc_update, 
    GL_NV_timer_query, GL_OES_compressed_ETC1_RGB8_texture, GL_OES_depth24, 
    GL_OES_depth32, GL_OES_depth_texture, GL_OES_depth_texture_cube_map, 
    GL_OES_EGL_image, GL_OES_EGL_sync, GL_OES_element_index_uint, 
    GL_OES_fbo_render_mipmap, GL_OES_get_program_binary, GL_OES_mapbuffer, 
    GL_OES_packed_depth_stencil, GL_OES_rgb8_rgba8, 
    GL_OES_standard_derivatives, GL_OES_surfaceless_context, 
    GL_OES_texture_npot, GL_OES_texture_half_float, 
    GL_OES_texture_half_float_linear, GL_OES_vertex_array_object, 
    GL_OES_vertex_half_float

What I tried kwin-gles; it was buggy as hell, although i have rather old kde(4.8.5).

[mannerov]

Hmh what egl specific extensions does wayland need? And what else does it need.

$ es2_info
EGL_VERSION = 1.4
EGL_VENDOR = NVIDIA
EGL_EXTENSIONS = EGL_NV_system_time EGL_KHR_surfaceless_context EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_config_attribs EGL_KHR_fence_sync EGL_NV_sync EGL_KHR_reusable_sync EGL_KHR_create_context EGL_EXT_create_context_robustness EGL_KHR_stream EGL_KHR_stream_fifo EGL_KHR_stream_producer_eglsurface EGL_KHR_stream_consumer_gltexture EGL_NV_stream_sync EGL_KHR_get_all_proc_addresses
EGL_CLIENT_APIS = OpenGL_ES
GL_VERSION: OpenGL ES 2.0 334.16
GL_RENDERER: GeForce GT 240/PCIe/SSE2
GL_EXTENSIONS:
    GL_EXT_blend_minmax, GL_EXT_color_buffer_float, 
    GL_EXT_color_buffer_half_float, GL_EXT_debug_label, GL_EXT_frag_depth, 
    GL_EXT_map_buffer_range, GL_EXT_occlusion_query_boolean, 
    GL_EXT_robustness, GL_EXT_separate_shader_objects, 
    GL_EXT_shader_integer_mix, GL_EXT_shadow_samplers, GL_EXT_sRGB, 
    GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_s3tc, 
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_format_BGRA8888, 
    GL_EXT_texture_sRGB_decode, GL_EXT_texture_storage, 
    GL_EXT_unpack_subimage, GL_KHR_debug, GL_NV_bgr, GL_NV_copy_buffer, 
    GL_NV_copy_image, GL_NV_draw_buffers, GL_NV_draw_instanced, 
    GL_NV_EGL_stream_consumer_external, GL_NV_explicit_attrib_location, 
    GL_NV_fbo_color_attachments, GL_NV_framebuffer_blit, 
    GL_NV_framebuffer_multisample, GL_NV_generate_mipmap_sRGB, 
    GL_NV_instanced_arrays, GL_NV_occlusion_query_samples, 
    GL_NV_non_square_matrices, GL_NV_pack_subimage, GL_NV_packed_float, 
    GL_NV_pixel_buffer_object, GL_NV_read_buffer, GL_NV_read_depth, 
    GL_NV_read_depth_stencil, GL_NV_read_stencil, GL_NV_shadow_samplers_array, 
    GL_NV_shadow_samplers_cube, GL_NV_sRGB_formats, GL_NV_texture_array, 
    GL_NV_texture_border_clamp, GL_NV_texture_compression_latc, 
    GL_NV_texture_compression_s3tc, GL_NV_texture_compression_s3tc_update, 
    GL_NV_timer_query, GL_OES_compressed_ETC1_RGB8_texture, GL_OES_depth24, 
    GL_OES_depth32, GL_OES_depth_texture, GL_OES_depth_texture_cube_map, 
    GL_OES_EGL_image, GL_OES_EGL_sync, GL_OES_element_index_uint, 
    GL_OES_fbo_render_mipmap, GL_OES_get_program_binary, GL_OES_mapbuffer, 
    GL_OES_packed_depth_stencil, GL_OES_rgb8_rgba8, 
    GL_OES_standard_derivatives, GL_OES_surfaceless_context, 
    GL_OES_texture_npot, GL_OES_texture_half_float, 
    GL_OES_texture_half_float_linear, GL_OES_vertex_array_object, 
    GL_OES_vertex_half_float

What I tried kwin-gles; it was buggy as hell, although i have rather old kde(4.8.5).

"EGL_KHR_stream EGL_KHR_stream_fifo EGL_KHR_stream_producer_eglsurface EGL_KHR_stream_consumer_gltexture EGL_NV_stream_sync" are supposed to allow to have EGL working with any display server. But it needs a device independent way to initialise EGL: see http://www.x.org/wiki/Events/XDC2013...nesEGLDevices/

Using these extensions for Wayland looks complicated (and probably doesn't fit very well), and it would be much better if they just decide to support Wayland directly.
The current way we do is: when we want to display something, you create a wl_buffer, and attach it to a wl_surface, and commit it. The wl_buffer can be a gl buffer, or an shm buffer, or whatever compatible. With a commit you can do other things (ask for a frame callback, etc)

EGLstream seems to be: a producer render frames, and a consumer listen and catch the frames and use it for displaying. So it's like you redo another protocol to commit frames.

[blackout23]

Probably needs a backend similar to the one used for the Pi which also has a proprierty driver?

http://ppaalanen.blogspot.co.uk/2013/05/weston-on-raspberry-pi-accelerated.html

http://lists.freedesktop.org/archives/wayland-devel/2012-November/006133.html

[mannerov]

Probably needs a backend similar to the one used for the Pi which also has a proprierty driver?

http://ppaalanen.blogspot.co.uk/2013/05/weston-on-raspberry-pi-accelerated.html

http://lists.freedesktop.org/archive...er/006133.html

In the XDC presentation, it is said that NVidia wants to have modesetting in EGL. If they do that, it'll need a specific backend.
But the backend has nothing to do with the way the compositor receive buffers.

[blackout23]

In the XDC presentation, it is said that NVidia wants to have modesetting in EGL. If they do that, it'll need a specific backend.

What's the benefit of this? Wouldn't every compositor have to ship this backend? If it gets merged into weston I think mutter-wayland is all set, since it uses weston as base iirc, but what about others? Someone has to maintain it, too.

[mannerov]

What's the benefit of this? Wouldn't every compositor have to ship this backend? If it gets merged into weston I think mutter-wayland is all set, since it uses weston as base iirc, but what about others? Someone has to maintain it, too.

Weston has a backend to use KMS for example. Here it would need a backend to use NVidia EGL modesetting.

In the presentation, they say the advantage for them is that it isn't linux specific, but they were not sure there was no better way. So perhaps they have changed their mind by then.

[Andrecorreia]

well..

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