Stephane Marchesin wrote:
Jerome, Dave, Keith
It's hard to argue against people trying things out and finding it's not
really what they want, so I'm not going to do that.
The biggest argument (apart from the fencing) seems to be that people
thinks TTM stops them from doing what they
On 5/18/08, Thomas Hellström [EMAIL PROTECTED] wrote:
What you fail to notice here is that I think most people intend to
have only one memory manager in the kernel.
How on earth can you draw that conclusion from the above statement?
Well, Dave has been saying this to me all along...
On Thu, 2008-05-15 at 07:30 +0200, Thomas Hellström wrote:
Static wc-d maps into fairly static objects like scanout buffers or
buffer pools are not inefficient. They provide the by far highest
throughput for writing (even beats cache-coherent). But they may take
some time to set up or tear
Keith Packard wrote:
On Thu, 2008-05-15 at 07:30 +0200, Thomas Hellström wrote:
Static wc-d maps into fairly static objects like scanout buffers or
buffer pools are not inefficient. They provide the by far highest
throughput for writing (even beats cache-coherent). But they may take
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
| On Wed, 2008-05-14 at 21:41 +0200, Thomas Hellström wrote:
|
| As you've previously mentioned, this requires caching policy changes and
| it needs to be used with some care.
|
| I did't need that in my drivers as GEM handles the
On Thu, 2008-05-15 at 10:03 -0700, Ian Romanick wrote:
Er...what about glMapBuffer? Are we now going to force drivers to
implement that via copies?
No, we'll support it, and make it as fast as possible. The goal is to
not use it inside the driver, not to break GL apps.
--
[EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt schrieb:
No. Gem can't coop with it. Let's say you have a 512M system with two 1G
video cards, 4G swap space, and you want to fill both card's videoram
with render-and-forget textures for whatever purpose.
Who's selling that
On Tue, 13 May 2008 21:35:16 +0100 (IST)
Dave Airlie [EMAIL PROTECTED] wrote:
1) I feel there hasn't been enough open driver coverage to prove it. So
far we have done an Intel IGD, we have a lot of code that isn't required
for these devices, so the question of how much code exists purely to
Jerome Glisse wrote:
On Tue, 13 May 2008 21:35:16 +0100 (IST)
Dave Airlie [EMAIL PROTECTED] wrote:
1) I feel there hasn't been enough open driver coverage to prove it. So
far we have done an Intel IGD, we have a lot of code that isn't required
for these devices, so the question of how
I do worry that TTM is not Linux enough, it seems you have decided that we
can never do in-kernel allocations at any useable speed and punted the
work into userspace, which makes life easier for Gallium as its more like
what Windows does, but I'm not sure this is a good solution for Linux.
1) I feel there hasn't been enough open driver coverage to prove it. So
far
we have done an Intel IGD, we have a lot of code that isn't required for
these devices, so the question of how much code exists purely to support
poulsbo closed source userspace there is and why we need to
On Wed, 14 May 2008 12:09:06 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
Jerome, Dave, Keith
1) The inability to map device memory. The design arguments and proposed
solution for VRAM are not really valid. Think of this, probably not too
uncommon, scenario of a
Jerome Glisse wrote:
On Wed, 14 May 2008 12:09:06 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
Jerome, Dave, Keith
1) The inability to map device memory. The design arguments and proposed
solution for VRAM are not really valid. Think of this, probably not too
Ben Skeggs wrote:
1) I feel there hasn't been enough open driver coverage to prove it. So far
we have done an Intel IGD, we have a lot of code that isn't required for
these devices, so the question of how much code exists purely to support
poulsbo closed source userspace there is and why we
On Wed, 2008-05-14 at 12:09 +0200, Thomas Hellström wrote:
1) The inability to map device memory. The design arguments and proposed
solution for VRAM are not really valid. Think of this, probably not too
uncommon, scenario of a single pixel fallback composite to a scanout
buffer in vram.
On Wed, 14 May 2008 16:36:54 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
I don't agree with you here. EXA is much faster for small composite
operations and even small fill blits if fallbacks are used. Even to
write-combined memory, but that of course depends on the
: Re: TTM merging?
On Wed, 14 May 2008 16:36:54 +0200
Thomas Hellström wrote:
Jerome Glisse wrote:
I don't agree with you here. EXA is much faster for small composite
operations and even small fill blits if fallbacks are used. Even to
write-combined memory, but that of course depends
On Wed, 14 May 2008 10:21:15 -0700 (PDT)
Keith Whitwell [EMAIL PROTECTED] wrote:
On Wed, 14 May 2008 16:36:54 +0200
Thomas Hellström wrote:
Jerome Glisse wrote:
I don't agree with you here. EXA is much faster for small composite
operations and even small fill blits if fallbacks
PROTECTED]
Sent: Wednesday, May 14, 2008 6:08:55 PM
Subject: Re: TTM merging?
On Wed, 14 May 2008 16:36:54 +0200
Thomas Hellström wrote:
Jerome Glisse wrote:
I don't agree with you here. EXA is much faster for small composite
operations and even small fill blits if fallbacks
On Wed, 2008-05-14 at 16:36 +0200, Thomas Hellström wrote:
2) Reserving pages when allocating VRAM buffers is also a very bad
solution particularly on systems with a lot of VRAM and little system
RAM. (Multiple card machines?). GEM basically needs to reserve
swap-space when buffers are
On Wed, 2008-05-14 at 02:33 +0200, Thomas Hellström wrote:
The real question is whether TTM suits the driver writers for use in Linux
desktop and embedded environments, and I think so far I'm not seeing
enough positive feedback from the desktop side.
I actually haven't seen much
On Wed, 2008-05-14 at 16:36 +0200, Thomas Hellström wrote:
My personal feeling is that pwrites are a workaround for a workaround
for a very bad decision
Feel free to map VRAM then if you can; I didn't need to on Intel as
there isn't any difference.
--
[EMAIL PROTECTED]
signature.asc
On Wed, 2008-05-14 at 19:08 +0200, Jerome Glisse wrote:
I don't have number or benchmark to check how fast pread/pwrite path might
be in this use so i am just expressing my feeling which happen to just be
to avoid vma tlb flush as most as we can.
For batch buffers, pwrite is 3X faster than
On Wed, 2008-05-14 at 10:21 -0700, Keith Whitwell wrote:
Nobody can force you to take one path or the other, but it's certainly
my intention when considering drivers for VRAM hardware to support
single-copy-number textures, and for that reason, I'd be unhappy to
see a system adopted that
Eric Anholt wrote:
On Wed, 2008-05-14 at 02:33 +0200, Thomas Hellström wrote:
The real question is whether TTM suits the driver writers for use in Linux
desktop and embedded environments, and I think so far I'm not seeing
enough positive feedback from the desktop side.
I
On Wed, May 14, 2008 at 2:30 PM, Eric Anholt [EMAIL PROTECTED] wrote:
On Wed, 2008-05-14 at 02:33 +0200, Thomas Hellström wrote:
The real question is whether TTM suits the driver writers for use in
Linux
desktop and embedded environments, and I think so far I'm not seeing
enough
Keith Packard wrote:
On Wed, 2008-05-14 at 10:21 -0700, Keith Whitwell wrote:
Nobody can force you to take one path or the other, but it's certainly
my intention when considering drivers for VRAM hardware to support
single-copy-number textures, and for that reason, I'd be unhappy to
see
Keith Packard wrote:
On Wed, 2008-05-14 at 16:36 +0200, Thomas Hellström wrote:
My personal feeling is that pwrites are a workaround for a workaround
for a very bad decision
Feel free to map VRAM then if you can; I didn't need to on Intel as
there isn't any difference.
With
Eric Anholt wrote:
If the implementation of those ioctls in generic code doesn't work for
some drivers (say, early shmfs object creation turns out to be a bad
idea for VRAM drivers), I'll happily push it out to the driver.
Or perhaps use generic ioctls, but provide hooks in the driver to
On Wed, 2008-05-14 at 21:41 +0200, Thomas Hellström wrote:
As you've previously mentioned, this requires caching policy changes and
it needs to be used with some care.
I did't need that in my drivers as GEM handles the WB - GPU object
transfer already.
Object mapping is really the least
On Wed, 2008-05-14 at 21:51 +0200, Thomas Hellström wrote:
Eric Anholt wrote:
If the implementation of those ioctls in generic code doesn't work for
some drivers (say, early shmfs object creation turns out to be a bad
idea for VRAM drivers), I'll happily push it out to the driver.
On Wed, May 14, 2008 at 03:48:47PM -0700, Keith Packard wrote:
| Object mapping is really the least important part of the system; it
| should only be necessary when your GPU is deficient, or your API so
| broken as to require this inefficient mechanism.
In the OpenGL case, object mapping wasn't
On Wed, 2008-05-14 at 16:34 -0700, Allen Akin wrote:
On Wed, May 14, 2008 at 03:48:47PM -0700, Keith Packard wrote:
| Object mapping is really the least important part of the system; it
| should only be necessary when your GPU is deficient, or your API so
| broken as to require this
On Wed, May 14, 2008 at 05:22:06PM -0700, Keith Packard wrote:
| On Wed, 2008-05-14 at 16:34 -0700, Allen Akin wrote:
| In the OpenGL case, object mapping wasn't originally a part of the API.
| It was added because people building hardware and apps for Intel-based
| PCs determined that it was
Keith Packard wrote:
On Wed, 2008-05-14 at 21:41 +0200, Thomas Hellström wrote:
As you've previously mentioned, this requires caching policy changes and
it needs to be used with some care.
I did't need that in my drivers as GEM handles the WB - GPU object
transfer already.
Dave,
Could you list what fixes / changes you think are needed to get TTM into
the mainline kernel?
2 main reasons:
1) I feel there hasn't been enough open driver coverage to prove it. So
far we have done an Intel IGD, we have a lot of code that isn't required
for these devices, so
Dave Airlie wrote:
Dave,
Could you list what fixes / changes you think are needed to get TTM into
the mainline kernel?
2 main reasons:
1) I feel there hasn't been enough open driver coverage to prove it. So
far we have done an Intel IGD, we have a lot of code that isn't required
1) I feel there hasn't been enough open driver coverage to prove it. So far
we have done an Intel IGD, we have a lot of code that isn't required for
these devices, so the question of how much code exists purely to support
poulsbo closed source userspace there is and why we need to live
Dave Airlie wrote:
1) I feel there hasn't been enough open driver coverage to prove it. So far
we have done an Intel IGD, we have a lot of code that isn't required for
these devices, so the question of how much code exists purely to support
poulsbo closed source userspace there is and why we
On 5/14/08, Dave Airlie [EMAIL PROTECTED] wrote:
I was hoping that by now, one of the radeon or nouveau drivers would have
adopted TTM, or at least demoed something working using it, this hasn't
happened which worries me, perhaps glisse or darktama could fill in on
what limited them from
40 matches
Mail list logo
