From: "Christian König" <christian.koenig@amd.com>
To: Alexander Fyodorov <halcy@yandex.ru>,
airlied@linux.ie, dri-devel@lists.freedesktop.org
Subject: Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory
Date: Thu, 9 Oct 2014 19:42:02 +0200 [thread overview]
Message-ID: <5436C8EA.4010200@amd.com> (raw)
In-Reply-To: <3692931412854762@web24j.yandex.ru>
Hi Alexander,
in the ring test we write the value 0xDEADBEEF and 0xCAFEDEAD into
registers, not VRAM.
And the register bar shouldn't be accessed write combined, cause that
could lead to a couple of ordering problems. Why do you think the access
is done write combined?
For VRAM it is true that we have a couple of different caches between
the CPU and the actually memory, which need to be flushed explicitly if
you want to see a value written by the GPU.
Regards,
Christian.
Am 09.10.2014 um 13:39 schrieb Alexander Fyodorov:
> Hi David,
>
> I'm using 3.10.53-rt56 kernel and encounter a problem in
> r600_dma_ring_test() when vram memory is mapped as write-combining:
> no matter how long the polling is done, old value (0xCAFEDEAD) is read.
>
> Looking with hardware analyzer at what actually happens in the PCI-E bus,
> the memory is accessed with 32-byte loads (8 words at a time). That is,
> when the memory is mapped as write-combining, the processor converts
> every readl() into a 32-bytes load transaction.
>
> After doing some more experiments, it seems that Radeon has some kind of
> cache that keeps the old value (0xCAFEDEAD), and this cache is invalidated
> when:
> 1) Some other VRAM address is accessed, or
> 2) Processor issues a 4-byte load transaction.
>
> The problem is that as long as the memory is write-combining, all loads
> will be converted to be 32-bytes long by the CPU, so the test fails with
> timeout. But if I comment out this particular ring test, everything
> seems to be working fine (tested with Doom 3).
>
> Is it possible that the situation r600_dma_ring_test() checks for does
> not happen in real life, and I should be OK commenting it out?
>
> Or maybe the test is broken and some cache-flushing command must be
> written into the ring buffer?
>
> BTW this is an out-of-tree architecture, so bisecting is not possible.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-10-09 17:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-09 11:39 r600_dma_ring_test() failed - synchronization problem with write-combining memory Alexander Fyodorov
2014-10-09 17:42 ` Christian König [this message]
2014-10-09 18:15 ` Alexander Fyodorov
2014-10-09 18:32 ` Christian König
2014-10-09 19:10 ` Alexander Fyodorov
2014-10-10 16:00 ` Alex Deucher
2014-10-10 16:02 ` Alex Deucher
2014-10-10 16:03 ` Christian König
2014-10-13 17:50 ` Alex Deucher
2014-10-14 14:12 ` Alexander Fyodorov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5436C8EA.4010200@amd.com \
--to=christian.koenig@amd.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=halcy@yandex.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.