linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Gerhard Pircher" <gerhard_pircher@gmx.net>
To: "\"Michel Dänzer\"" <michel@daenzer.net>
Cc: schwab@linux-m68k.org, ojordan12345@hotmail.co.uk,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: PowerPC radeon KMS - is it possible?
Date: Thu, 19 Apr 2012 13:48:25 +0200	[thread overview]
Message-ID: <20120419114825.203090@gmx.net> (raw)
In-Reply-To: <1334817171.5989.366.camel@thor.local>


-------- Original-Nachricht --------
> Datum: Thu, 19 Apr 2012 08:32:51 +0200
> Von: "Michel Dänzer" <michel@daenzer.net>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: ojordan12345@hotmail.co.uk, schwab@linux-m68k.org, linuxppc-dev@lists.ozlabs.org
> Betreff: Re: PowerPC radeon KMS - is it possible?

> On Mit, 2012-04-18 at 18:23 +0200, Gerhard Pircher wrote: 
> > > Von: "Michel Dänzer" <michel@daenzer.net>
> > > On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote: 
> > > > > Von: "Michel Dänzer" <michel@daenzer.net>
> > > > > On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote: 
> > > > > > Michel Dänzer <michel@daenzer.net> writes:
> > > > > > 
> > > > > > > On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: 
> > > > > > >> Michel Dänzer <michel@daenzer.net> writes:
> > > > > > >> 
> > > > > > >> > Have you tried smaller aperture sizes
> (uninorth_agp.aperture)
> > > > > > >> > and/or radeon.test=1? (See commit
> > > > > > >> > 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c)
> > > > > > >> 
> > > > > > >> Neither changes anything.
> > > > > > >
> > > > > > > How small aperture sizes have you tried?
> > > > > > 
> > > > > > 32M. With the old UMS driver 3D once worked fine ...
> > > > > 
> > > > > That doesn't necessarily mean much per se, as with UMS memory is
> > > > > only statically mapped into the AGP GART once (so most of those
> > > > > 32M are wasted at least most of the time), whereas with KMS it's
> > > > > dynamically (un)mapped on demand.
> > > > That may be a stupid question, but is it allowed (for a DRM client
> > > > or whatever does the mapping) to change the content of a page
> > > > mapped into the AGP GART or is it necessary to explicitly unmap
> > > > the page, change its content and map it again?
> > > 
> > > The former.
> > I know that the uninorth AGPGART driver does a cache flushing for
> > newly mapped pages,
> 
> Ah, right, that probably explains why the map_page_into_agp change
> doesn't make any difference.
> 
> 
> > but is there any code in the driver that handles the former case (or
> > isn't this necessary on PPC Macs)?
> 
> If by 'former case' you mean userspace modifying memory mapped into the
> AGP GART, then no, this generally doesn't require special treatment on
> PowerMacs. (Ignoring the potential issue mentioned by Ben in this
> thread)
I guess you refer to the ordering issue here.

The "former case" is an explanation, why I see data corruption with my
AGPGART driver (more or less a copy of the uninorth driver) on my
non-coherent platform. There are no cache flushes done for writes to
already mapped pages.
I tested this with radeon.test=1, but I'm not even sure if this code
changes already mapped pages (all of this makes it hard to tell for
me whether I stumble over a severe hardware error and/or a "simple"
coherency problem).

> > > > I would say it's necessary to unmap the page first (sounds more
> > > > like the pci_[un]map_page() approach) - at least when it should
> > > > work with non-coherent architectures, too.
> > > 
> > > I'm afraid non-coherent platforms haven't really been a concern yet
> > > for KMS, and always doing the above dance would probably have a
> > > significant performance impact on coherent platforms.
> > Are there any plans for a page flushing API? I suppose that wouldn't
> > have such a big performance impact on coherent platforms (but probably
> > an impact on the userspace API).
> 
> Not that I know of.
> 
> Note that this isn't necessarily the only possible approach for
> addressing this problem. The driver knows which memory buffers are used
> by a GPU command stream sequence, so it should be able to take any
> measures necessary to ensure the device sees their contents as of when
> the command stream was submitted.
Good to hear! Anyway the TTM backend and the KMS drivers are a way
too complex for me so that I can only hope there will be a solution
for non-coherent platforms someday. :-)

Thanks for the clarification!

Gerhard
-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

  reply	other threads:[~2012-04-19 11:48 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-17 19:49 PowerPC radeon KMS - is it possible? o jordan
2012-04-18  6:35 ` Michel Dänzer
2012-04-18  6:59 ` Benjamin Herrenschmidt
     [not found] ` <1334730915.5989.265.camel__41553.0639271767$1334731329$gmane$org@thor.local>
2012-04-18  7:42   ` Andreas Schwab
2012-04-18  7:52     ` Michel Dänzer
2012-04-18 11:25       ` Andreas Schwab
2012-04-18 13:02         ` Michel Dänzer
2012-04-18 13:22           ` Andreas Schwab
2012-04-18 13:25             ` Michel Dänzer
2012-04-18 13:47               ` Andreas Schwab
2012-04-18  7:54   ` Andreas Schwab
2012-04-18  8:02     ` Michel Dänzer
2012-04-18 10:20       ` Benjamin Herrenschmidt
2012-04-18 10:34         ` Michel Dänzer
2012-04-18 10:44           ` Michel Dänzer
2012-04-18 11:19             ` Benjamin Herrenschmidt
2012-04-18 13:08               ` Michel Dänzer
2012-04-18 12:49             ` Andreas Schwab
2012-04-18 11:17           ` Benjamin Herrenschmidt
2012-04-18 13:27             ` Michel Dänzer
2012-04-18 11:30       ` Andreas Schwab
2012-04-18 13:38         ` Michel Dänzer
2012-04-18 14:28           ` Andreas Schwab
2012-04-18 14:31             ` Michel Dänzer
2012-04-18 14:55               ` Andreas Schwab
2012-04-18 15:01                 ` Michel Dänzer
2012-04-18 15:49                   ` Gerhard Pircher
2012-04-18 16:06                     ` Michel Dänzer
2012-04-18 16:23                       ` Gerhard Pircher
2012-04-19  6:32                         ` Michel Dänzer
2012-04-19 11:48                           ` Gerhard Pircher [this message]
2012-04-19 12:41                             ` Michel Dänzer
2012-04-18 15:39       ` Andreas Schwab
     [not found] ` <1334732346.1159.5.camel__22339.9641145535$1334732429$gmane$org@pasglop>
2012-04-18  7:46   ` Andreas Schwab
2012-04-18 10:35     ` Benjamin Herrenschmidt
2012-04-18 10:37       ` Benjamin Herrenschmidt
2012-04-18 10:54         ` Michel Dänzer
2012-04-18 11:23           ` Benjamin Herrenschmidt
2012-04-18 13:07             ` Michel Dänzer
2012-04-18 22:25               ` Benjamin Herrenschmidt
  -- strict thread matches above, loose matches on Subject: below --
2012-04-20 11:15 Gerhard Pircher
2012-04-20 13:18 ` Michel Dänzer
2012-04-20 16:14   ` Gerhard Pircher
2012-04-23  9:56     ` Michel Dänzer
2012-04-23 16:45       ` Gerhard Pircher
2012-04-24 14:15         ` Michel Dänzer
2012-04-24 17:10           ` Gerhard Pircher

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=20120419114825.203090@gmx.net \
    --to=gerhard_pircher@gmx.net \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=michel@daenzer.net \
    --cc=ojordan12345@hotmail.co.uk \
    --cc=schwab@linux-m68k.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).