Initial DRI3000 protocol specs available

[Kristian Høgsberg]

On Fri, Mar 8, 2013 at 3:59 AM, James Jones <jajones at nvidia.com> wrote:
> On 03/07/2013 05:17 PM, Keith Packard wrote:
>>
>> * PGP Signed by an unknown key
>>
>> James Jones <jajones at nvidia.com> writes:
>>
>>> There didn't seem to be much interest outside of NVIDIA, so
>>> besides fence sync, the ideas are tabled internally ATM.
>>
>>
>> This shouldn't surprise you though -- no-one else needs this kind of
>> synchronization, so it's really hard for anyone to evaluate it. And,
>> DRI2 offers 'sufficient' support for the various GL sync extensions.
>
> I was referring to the multi-buffer/tear-free presentation part, not the
> synchronization parts.  I still rather surprised everyone thinks implicit
> synchronization is a good idea though.  I don't think we're the only ones
> that have loosely defined command buffer processing in HW anymore.  Meh.

It's not that other hw don't have that (or even other drivers for your
hw, ie nouveau).  Serializing through the kernel execution manager
lets the kernel know the the expected order of rendering.  If
rendering in hw queue A depends on a result from a hw queue B (B
renders to buffer, A textures from same buffer),  the kernel can
insert synchronization primitives to ensure that the A queue doesn't
proceed before the B queue signals the fence.  If A and B queues don't
have any inter-dependencies, no synchronization is necessary and they
can run in parallel or out of order.

Kristian