From: "Michel Dänzer" <michel@daenzer.net>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: radeonsi tiling dilema
Date: Wed, 03 Apr 2013 18:11:26 +0200 [thread overview]
Message-ID: <1365005486.10575.8.camel@thor.local> (raw)
In-Reply-To: <CAH3drwaHZnaHWNiFC61zTfFMjTvKBOjW0nZC9qHRcomx0rKuFw@mail.gmail.com>
On Mit, 2013-04-03 at 09:57 -0400, Jerome Glisse wrote:
> On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer <michel@daenzer.net>
> wrote:
> On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote:
> >
> > Some might argue that we could just export the table content
> to
> > userspace, but that would loose information and possibly
> froze the
> > tile mode table forever as API.
The current index scheme already is de facto part of the API.
> The information we loose is what index
> > match to prefered surface format/type combination.
How so? We can add descriptive names for the existing indices.
> And the tile mode
> > might be considered API as if kernel ever change what
> userspace expect
> > then we might break some userspace.
Not sure how that could happen if the purpose of each index is clearly
defined.
> Maybe I'm missing the problem, but if libdrm_radeon were to
> get the
> tiling mode index chosen by radeonsi, and could retrieve the
> tiling
> parameters for each index from the kernel, it should be able
> to
> calculate things properly, shouldn't it?
>
>
>
> Let's not discuss about who/where the index is pick. No matter where
> it happens the question is do we want to hardcode tile index and make
> it api or do we want to hide it behind symbolic name allowing change
> in tile array (given that right now 4 value are already frozen). You
> can look at my kernel patch to see what i mean.
The layer of indirection for the indices seems like overengineering at
this point. Even if the fixed indices stop being good enough for some
reason in the future, how can we be sure now the layer of indirection
will be good enough? So I think we shouldn't worry about that until that
day may come.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2013-04-03 16:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-02 18:13 radeonsi tiling dilema Jerome Glisse
2013-04-02 18:47 ` Jerome Glisse
2013-04-02 20:32 ` Alex Deucher
2013-04-02 22:28 ` Jerome Glisse
2013-04-03 9:37 ` Michel Dänzer
2013-04-03 13:57 ` Jerome Glisse
2013-04-03 15:48 ` Christian König
2013-04-03 15:57 ` Alex Deucher
2013-04-04 9:00 ` Christian König
2013-04-03 16:11 ` Michel Dänzer [this message]
2013-04-03 17:04 ` Jerome Glisse
2013-04-04 7:42 ` Michel Dänzer
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=1365005486.10575.8.camel@thor.local \
--to=michel@daenzer.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=j.glisse@gmail.com \
/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.