[Mesa-dev] [PATCH 5/6] i965: Upload binding tables in hw-generated binding table format.

Chris Wilson chris at chris-wilson.co.uk
Fri Jun 26 04:17:19 PDT 2015


On Fri, Jun 26, 2015 at 01:59:17PM +0300, Abdiel Janulgue wrote:
> 
> 
> On 06/26/2015 10:55 AM, Chris Wilson wrote:
> > On Fri, Jun 26, 2015 at 08:52:01AM +0300, Abdiel Janulgue wrote:
> >> When hardware-generated binding tables are enabled, use the hw-generated
> >> binding table format when uploading binding table state.
> >>
> >> Normally, the CS will will just consume the binding table pointer commands
> >> as pipelined state. When the RS is enabled however, the RS flushes whatever
> >> edited surface state entries of our on-chip binding table to the binding
> >> table pool before passing the command on to the CS.
> >>
> >> Note that the the binding table pointer offset is relative to the binding table
> >> pool base address when resource streamer instead of the surface state base address.
> >>
> >> v2: Fix possible buffer overflow when allocating a chunk out of the
> >>     hw-binding table pool (Ken).
> > 
> > If I am reading this correctly, the binding table store offsets relative
> > to the surface-state base address. It would seem that separating the
> > surfaces into their own state bo would cut down on the amount of RS
> > traffic (you would not need to reload the binding table bo every batch,
> > nor change the entries as often). Right?
> 
> We tried this approach already around a couple of years ago*. Yes, it
> did cut down the traffic but didn't offer any performance improvements.

It would be great if you could record the results of those
investigations next to the RS work. It helps documents the why's of the
design, and helps people to reproduce those earlier results and try
different directions.

The final message in that thread is "I think I know why
this didn't show the results I expected, I will go away and try
different benchmarks..."

Besides which the counter arguments of delaying free or having to use a
hash do not apply with an alternative libdrm interface.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the mesa-dev mailing list