Announcement

Collapse
No announcement yet.

NVIDIA 334.16 Beta Supports 64-bit EGL / OpenGL ES

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    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.

    Comment


    • #22
      Originally posted by Tobu View Post
      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.

      Comment


      • #23
        On mi case this drivers works good with wine 1.7.12



        Comment


        • #24
          Hmh what egl specific extensions does wayland need? And what else does it need.
          Code:
          $ 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).

          Comment


          • #25
            Originally posted by tuke81 View Post
            Hmh what egl specific extensions does wayland need? And what else does it need.
            Code:
            $ 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.
            Last edited by mannerov; 02-08-2014, 12:14 PM.

            Comment


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

              http://ppaalanen.blogspot.co.uk/2013...celerated.html

              http://lists.freedesktop.org/archive...er/006133.html
              Last edited by blackout23; 02-08-2014, 12:24 PM.

              Comment


              • #27
                Originally posted by blackout23 View Post
                Probably needs a backend similar to the one used for the Pi which also has a proprierty driver?

                http://ppaalanen.blogspot.co.uk/2013...celerated.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.

                Comment


                • #28
                  Originally posted by mannerov View Post
                  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.

                  Comment


                  • #29
                    Originally posted by blackout23 View Post
                    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.

                    Comment


                    • #30
                      well..

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

                      Comment

                      Working...
                      X