Announcement

Collapse
No announcement yet.

NVIDIA 334.16 Beta Supports 64-bit EGL / OpenGL ES

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

  • #16
    Originally posted by bakgwailo View Post
    And KMS isn't needed for anything as long as the driver provides its own mechanism. As has been said mainy times before, the lack of KMS is a moot point in the NVidia driver.
    also a couple posts up

    Comment


    • #17
      Originally posted by bakgwailo View Post
      And KMS isn't needed for anything as long as the driver provides its own mechanism. As has been said mainy times before, the lack of KMS is a moot point in the NVidia driver.
      It's needed for a KMS console framebuffer. Also, the kernel can display error messages when it panics even if you're in X11. Without KMS, all you see is a frozen X11 screen. You'll never see the kernel error message.

      Windows has the BSOD for this purpose. Linux has KMS for this.
      Last edited by RealNC; 02-08-2014, 04:19 AM.

      Comment


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

        Comment


        • #19
          Originally posted by Tobu View Post
          KMS is also needed for a clean, graphical, flicker-free boot. NVIDIA still has large smudgy VESA characters.
          Nope that's another popular myth. It's because of fbcon.

          Comment


          • #20
            Originally posted by RealNC View Post
            Also, the kernel can display error messages when it panics even if you're in X11. Without KMS, all you see is a frozen X11 screen. You'll never see the kernel error message.

            Windows has the BSOD for this purpose. Linux has KMS for this.
            No, Linux has the drm panic notifier for this. There's no reason why Nvidia couldn't have their own panic notifier in their driver that simply switches away from X, as the drm panic notifier does. So again, KMS is not a requirement, it's just one possible way to implement something.

            Comment


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