Re: [RFC] drm/i915: Emit to ringbuffer directly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 09/09/16 14:45, Chris Wilson wrote:
On Fri, Sep 09, 2016 at 09:32:50AM +0100, Tvrtko Ursulin wrote:

On 08/09/16 17:40, Chris Wilson wrote:
On Thu, Sep 08, 2016 at 04:12:55PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>

This removes the usage of intel_ring_emit in favour of
directly writing to the ring buffer.

I have the same patch! But I called it out, for historical reasons.

Yes I know we talked about it in the past but I did not think you
will find time to actually write it amongst all the other things.

Oh, except mine uses out[0]...out[N] because gcc prefers that over
*out++ = ...

It copes just fine with the latter here, for example:

	*rbuf++ = cmd;
	*rbuf++ = I915_GEM_HWS_SCRATCH_ADDR | MI_FLUSH_DW_USE_GTT;
	*rbuf++ = 0; /* upper addr */
	*rbuf++ = 0; /* value */

Is:

      3e9:       89 10                   mov    %edx,(%rax)
      3eb:       c7 40 04 04 01 00 00    movl   $0x104,0x4(%rax)
      3f2:       c7 40 08 00 00 00 00    movl   $0x0,0x8(%rax)
      3f9:       c7 40 0c 00 00 00 00    movl   $0x0,0xc(%rax)

Last time Dave suggested using something like

i915_gem_request_emit(req, (struct cmd_packet){ dw0, dw1, dw2 });

I tried mocking something up, but just found gcc was constructing the
struct on the stack and then copying across, and generating far more
code than the sequence above. Worth seeing if that is better (or if my
mockup was just bad).

Not sure that I like that. It would be a bit ugly in cases where batches are built dynamically, no? Perhaps I am misunderstanding the idea?

Regards,

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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux