On Mon, May 08, 2017 at 02:35:06PM -0600, Jordan Crouse wrote:
> -#define rbmemptr(adreno_gpu, member) \
> +#define _sizeof(member) \
> + sizeof(((struct adreno_rbmemptrs *) 0)->member[0])
> +
> +#define _base(adreno_gpu, member) \
> ((adreno_gpu)->memptrs_iova + offsetof(struct adreno_rbmemptrs, member))
>
> +#define rbmemptr(adreno_gpu, index, member) \
> + (_base((adreno_gpu), member) + ((index) * _sizeof(member)))
> +
> struct adreno_rbmemptrs {
> - volatile uint32_t rptr;
> - volatile uint32_t fence;
> + volatile uint32_t rptr[MSM_GPU_MAX_RINGS];
> + volatile uint32_t fence[MSM_GPU_MAX_RINGS];
> };
I'm looking for opinions on moving this to a per-ring buffer object. It would be
a lot simpler to understand but it would cost us a page per ring as opposed
to the 1 page we use now.
Looking ahead we are going to want to start using trace messages in conjunction
with tools like systrace:
(https://developer.android.com/studio/profile/systrace-commandline.html)
This will involve tracking the always on counter value at start/retire for each
outstanding submit on each ring. I *think* we could fit those values into the
existing rmemptrs buffer if we wanted to but I can't imagine these would be the
last runtime statistics we would gather.
I guess I'm leaning toward the per-ring solution but I'll listen to anybody
argue that the memory usage isn't worth it.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
