On Fri, 2011-03-11 at 06:05 +0100, Marek Olšák wrote:
> Hi,
> 
> these 2 patches add GL_NV_texture_barrier to Mesa and Gallium,
> respectively. The extension can be used for programmable
> blending, where the same texture can be bound as both a sampler
> and renderbuffer. The same feature exists in Direct10 and
> the entry point is:
> 
> VOID APIENTRY ResourceReadAfterWriteHazard(
>   __in  D3D10DDI_HDEVICE hDevice,
>   __in  D3D10DDI_HRESOURCE hResource
> )
> 
> I have chosen the same name for Gallium:
> 
> void (*resource_read_after_write_hazard)(struct pipe_context *,
>                                          struct pipe_resource *)
> 
> The function is documented in the second patch.
> There is a new piglit test too, called blending-in-shader.
> I only have working r300g support, but I may add softpipe
> if needed.

I support this goal, but think you've probably chosen the wrong name for
the function.

The call you're introducing is a method for the application to cooperate
with the driver to get meaningful results when a single resource is
bound for read & write at the same time.

In DX10-land, ResourceReadAfterWriteHazard() is something generated
internally by the runtime when a resource which was previously bound to
write is being rebound to read from, ie. something like:

   if (ctx->is_resource_referenced(ctx, resource))
       ctx->flush(ctx);

From their docs: "The ResourceReadAfterWriteHazard function informs the
user-mode display driver that the specified resource was used as an
output from the graphics processing unit (GPU) and that the resource
will be used as an input to the GPU." 

And: "The Microsoft Direct3D runtime calls ResourceReadAfterWriteHazard
immediately before the specified resource is bound as an input to the
GPU."

Binding a single subresource for reading and writing at the same time is
(to my knowledge) not permitted in DX10.

So my suggestion would be to name this something else, perhaps taking
language from the NV extension.

Keith



_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to