On Fri, Mar 11, 2011 at 2:56 PM, Keith Whitwell <kei...@vmware.com> wrote:
> 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. > Alright. There are two patches attached in this email. The former is my attempt at display list support that I missed. The latter changes the gallium entry point to: void (*texture_barrier)(struct pipe_context *); Please review. Best regards Marek
0001-mesa-add-display-list-support-for-NV_texture_barrier.patch
Description: application/pgp-keys
0002-gallium-add-NV_texture_barrier-support-to-the-interf.patch
Description: application/pgp-keys
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
