Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: An OpenGL Optimization Extension Merged Into Mesa

  1. #11

    Default

    The one thing I've never understood though is that all of these work is done completely out of order. It doesn't make sense to get a bunch or parts in 4.x working before 4.0 is working so that you can actually make good use of the spec.

  2. #12
    Join Date
    May 2007
    Posts
    319

    Default

    Quote Originally Posted by Kivada View Post
    The one thing I've never understood though is that all of these work is done completely out of order. It doesn't make sense to get a bunch or parts in 4.x working before 4.0 is working so that you can actually make good use of the spec.

    why doesn't it? some apps can use extensions without the functionality level increase, though in some places the GLSL version increase is really important in others not so much.

    Also some developers aren't up to the commitment to the full time task of doing something like geometry or tessellation shaders but have the spare time to add other smaller pieces of functionality and leave the bigger pieces to the full time devs.

    Like I've no bandwidth to work on GL4.0 features, but I like to tinker around the edges and look at adding small extensions.

    Intel have plans to get to GL4, but they can't control what independent devs work on anyways, you seem unfamiliar with open source.

    Dave.

  3. #13
    Join Date
    Aug 2011
    Location
    Hillsboro, Oregon
    Posts
    129

    Default

    Some of the weird ordering is due to needs - if some program needs a specific feature, we'll do that first. The extension mechanism allows us to expose everything one piece at a time anyway.

    Other parts of 4.x get done quickly because they're small and simple, while the remaining GL 3.x features are large and difficult. Lots of people can jump in and implement a simple 4.x extension, but not everybody is up for writing a full geometry shader implementation.

  4. #14
    Join Date
    Aug 2011
    Posts
    502

    Default

    Quote Originally Posted by Kayden View Post
    Some of the weird ordering is due to needs - if some program needs a specific feature, we'll do that first. The extension mechanism allows us to expose everything one piece at a time anyway.

    Other parts of 4.x get done quickly because they're small and simple, while the remaining GL 3.x features are large and difficult. Lots of people can jump in and implement a simple 4.x extension, but not everybody is up for writing a full geometry shader implementation.
    As an example for this, how trivial would it be to add the GL_ARB_clear_texture extension within the current codebase?

  5. #15
    Join Date
    Dec 2012
    Posts
    23

    Default

    Not trivial, but also not horrendous.

  6. #16
    Join Date
    Aug 2011
    Location
    Hillsboro, Oregon
    Posts
    129

    Default

    Quote Originally Posted by Ancurio View Post
    As an example for this, how trivial would it be to add the GL_ARB_clear_texture extension within the current codebase?
    I'd estimate about a week...two if it goes badly, less if it goes well.

  7. #17
    Join Date
    Jan 2009
    Posts
    610

    Default

    Quote Originally Posted by Ancurio View Post
    As an example for this, how trivial would it be to add the GL_ARB_clear_texture extension within the current codebase?
    1 day if you know what to do. A lot more if you don't. Gallium has this already, the driver entrypoints are pipe_context::clear_render_target and pipe_context::clear_depth_stencil. Off the top of my head, they should already be implemented by all Radeon drivers, softpipe, and llvmpipe. If any driver doesn't implement the entrypoints, you can copy what softpipe does, which just calls generic utility functions. That should allow you to advertise GL_ARB_clear_texture for all Gallium drivers unconditionally.

  8. #18
    Join Date
    Aug 2011
    Posts
    502

    Default

    Quote Originally Posted by marek View Post
    1 day if you know what to do. A lot more if you don't. Gallium has this already, the driver entrypoints are pipe_context::clear_render_target and pipe_context::clear_depth_stencil. Off the top of my head, they should already be implemented by all Radeon drivers, softpipe, and llvmpipe. If any driver doesn't implement the entrypoints, you can copy what softpipe does, which just calls generic utility functions. That should allow you to advertise GL_ARB_clear_texture for all Gallium drivers unconditionally.
    Well yeah, that makes sense, as the glClearTexImage call would do little more than a classic glClear with an FBO targeting the texture bound.
    Can these gallium entry points you listed also clear arbitrary subrectangles of render targets? Actually, I'll go check in the code myself..

    Sounds like the perfect little patch to get someone started who wants to get into Mesa/Gallium development =)

  9. #19
    Join Date
    Aug 2011
    Posts
    502

    Default

    Code:
    /**
        * Clear a color rendertarget surface.
        * \param color  pointer to an union of fiu array for each of r, g, b, a.
        */
       void (*clear_render_target)(struct pipe_context *pipe,
                                   struct pipe_surface *dst,
                                   const union pipe_color_union *color,
                                   unsigned dstx, unsigned dsty,
                                   unsigned width, unsigned height);
    I guess that means yes.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •