Re: [PATCH v3] drm/i915: Replace gen6 semaphore signal table with code

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 22/07/16 13:42, Dave Gordon wrote:
> On 21/07/16 14:46, Tvrtko Ursulin wrote:
>> On 21/07/16 14:31, Chris Wilson wrote:
>>> On Thu, Jul 21, 2016 at 02:16:22PM +0100, Tvrtko Ursulin wrote:
>>>>
>>>> On 21/07/16 13:59, Chris Wilson wrote:
>>>>> On Thu, Jul 21, 2016 at 01:00:47PM +0100, Tvrtko Ursulin wrote:
>>>>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>>
>>>>>> Static table wastes space for invalid combinations and
>>>>>> engines which are not supported by Gen6 (legacy semaphores).
>>>>>>
>>>>>> Replace it with a function devised by Dave Gordon.
>>>>>>
>>>>>> I have verified that it generates the same mappings between
>>>>>> mbox selectors and signalling registers.
>>>>>
>>>>> So just how big was that table? How big are the functions replacing
>>>>> it?
>>>>
>>>> With I915_NUM_ENGINES of 5 table is 5 * 5 * (2 * 4) = 200 bytes.
>>>>
>>>> With the patch .text grows by 144 bytes here and .rodata shrinks by
>>>> 256. So a net gain of 112 bytes with my config. Conclusion is that
>>>> as long as we got five engines it is not that interesting to get rid
>>>> of the table.
>
> Since the semaphore matrix is only relevant to a specific gen, you could
> remove it from the multi-generational engine-list and instead just have
> it in the gen-specific code that needs it. That way it won't continue to
> grow as new engines are added. The one gen that needs it is fixed at
> 4x4, so it could just be a 16-byte lookup table, or 32 bits
> (0b11001001_10110001_00101101_10010011) if you really want to save space
> ;-)

Not so much save space today as prevent from it exploding in the future.

Rewriting the table to use hw_ids sounds like the best idea so far so 
I'll go with that.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx