On Tue, May 23, 2023 at 11:20:54AM -0700, Dixit, Ashutosh wrote:
On Mon, 22 May 2023 15:08:42 -0700, Umesh Nerlige Ramappa wrote:
Hi Umesh,
On Mon, May 22, 2023 at 01:20:12PM -0700, Dixit, Ashutosh wrote:
> On Fri, 19 May 2023 15:56:42 -0700, Umesh Nerlige Ramappa wrote:
>>
>> On DG2,
On Mon, 22 May 2023 15:08:42 -0700, Umesh Nerlige Ramappa wrote:
>
Hi Umesh,
> On Mon, May 22, 2023 at 01:20:12PM -0700, Dixit, Ashutosh wrote:
> > On Fri, 19 May 2023 15:56:42 -0700, Umesh Nerlige Ramappa wrote:
> >>
> >> On DG2, capturing OA reports while running heavy render workloads
> >>
On Mon, May 22, 2023 at 01:20:12PM -0700, Dixit, Ashutosh wrote:
On Fri, 19 May 2023 15:56:42 -0700, Umesh Nerlige Ramappa wrote:
Hi Umesh,
On DG2, capturing OA reports while running heavy render workloads
sometimes results in invalid OA reports where 64-byte chunks inside
reports have
On Fri, 19 May 2023 15:56:42 -0700, Umesh Nerlige Ramappa wrote:
>
Hi Umesh,
> On DG2, capturing OA reports while running heavy render workloads
> sometimes results in invalid OA reports where 64-byte chunks inside
> reports have stale values. Under memory pressure, high OA sampling rates
>
Hi Umesh,
Looks like there is still a problem with the if block moving the
stream->oa_buffer.tail forward.
An application not doing any polling would still run into the same problem.
If I understand correctly this change, it means the time based
workaround doesn't work.
We need to actually
On DG2, capturing OA reports while running heavy render workloads
sometimes results in invalid OA reports where 64-byte chunks inside
reports have stale values. Under memory pressure, high OA sampling rates
(13.3 us) and heavy render workload, occassionally, the OA HW TAIL
pointer does not
