From: "Jerome Glisse" <j.glisse@gmail.com>
To: "Thomas Hellström" <thomas@tungstengraphics.com>
Cc: "Keith Packard" <keithp@keithp.com>,
dri-devel@lists.sourceforge.net,
"Dave Airlie" <airlied@gmail.com>,
"Linux Kernel" <linux-kernel@vger.kernel.org>,
"Jesse Barnes" <jbarnes@virtuousgeek.org>
Subject: Re: [RFC] [PATCH] DRM TTM Memory Manager patch
Date: Fri, 4 May 2007 14:52:26 +0200 [thread overview]
Message-ID: <4240b9160705040552n222126a2iadef5452c722b63@mail.gmail.com> (raw)
In-Reply-To: <463B27C4.3040304@tungstengraphics.com>
On 5/4/07, Thomas Hellström <thomas@tungstengraphics.com> wrote:
> I was actually referring to an example where two clients need to have a
> buffer mapped and access it at exactly the same time.
> If there is such a situation, we have no other choice than to drop the
> buffer locking on map. If there isn't we can at least consider other
> alternatives that resolve the deadlock issue but that also will help
> clients synchronize and keep data coherent.
>
> /Thomas
One might be a texture where a portion is updated by one thread
and another portion update by another one, i believe the application
will know better than us if such concurrent access will conflict or not.
If this both thread access different pixel it make sense to let them
work together at the same time on the texture. If they are writing
to same pixel then they will have to sync between them so they
don't do somethings stupid.
My point is that the user space will know better if sync is needed
or not and how to sync access to the same buffer. Moreover we
can still add a locking mechanism in user space (in libdrm for
instance).
There is very likely others use case for such concurrent access which
i can't think off right now.
best,
Jerome Glisse
next prev parent reply other threads:[~2007-05-04 12:52 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-26 6:55 Dave Airlie
2007-04-27 16:39 ` Greg KH
2007-04-30 23:10 ` Dave Airlie
2007-04-30 23:50 ` Dave Jones
2007-05-01 0:10 ` Thomas Hellström
2007-05-01 22:36 ` Ingo Oeser
2007-05-02 3:59 ` Greg KH
2007-05-02 20:21 ` Eric Anholt
2007-05-02 23:01 ` Thomas Hellström
2007-05-04 4:07 ` Keith Packard
2007-05-04 8:07 ` Thomas Hellström
2007-05-04 8:49 ` Jerome Glisse
2007-05-04 9:40 ` Jerome Glisse
2007-05-04 15:28 ` Keith Packard
2007-05-04 11:03 ` Thomas Hellström
2007-05-04 11:57 ` Jerome Glisse
2007-05-04 12:32 ` Thomas Hellström
2007-05-04 12:52 ` Jerome Glisse [this message]
2007-05-04 15:32 ` Keith Packard
2007-05-04 15:15 ` Keith Packard
2007-05-04 15:57 ` Keith Whitwell
2007-05-04 16:26 ` Keith Packard
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=4240b9160705040552n222126a2iadef5452c722b63@mail.gmail.com \
--to=j.glisse@gmail.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=jbarnes@virtuousgeek.org \
--cc=keithp@keithp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=thomas@tungstengraphics.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®