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

[Abdiel Janulgue]

On 06/26/2015 02:17 PM, Chris Wilson wrote:
> 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.
> 

Hi Chris,

> 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 wh
> 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.

I agree with you there there should have been more benchmarks to
validate that idea. I'm not completely against resurrecting that
approach again. It was just at that time, my hands were already too full
and I had the impression that people were against it.

For the time being, I'm just hoping to have the basic hw-gen binding
tables functionality to get merged and then I hope to revisit those
optimisations again at some point (they require some extensive gutting
of the surface state setup in the i965 driver).

-Abdiel