An OpenGL Optimization Extension Merged Into Mesa

[Kivada]

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.

[airlied]

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.

[Kayden]

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.

[Ancurio]

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?

[chrisf]

Not trivial, but also not horrendous.

[Kayden]

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.

[marek]

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.

[Ancurio]

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 =)

[Ancurio]

/**
    * 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.