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
- Original Message
From: Jerome Glisse [EMAIL PROTECTED]
To: Thomas Hellström [EMAIL PROTECTED]
Cc: Dave Airlie [EMAIL PROTECTED]; Keith Packard [EMAIL PROTECTED]; DRI
dri-devel@lists.sourceforge.net; Dave Airlie [EMAIL PROTECTED]
Sent: Wednesday, May 14, 2008 6:08:55 PM
Subject:
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
On Wed, 2008-05-14 at 10:21 -0700, Keith Whitwell wrote:
- Original Message
From: Jerome Glisse [EMAIL PROTECTED]
To: Thomas Hellström [EMAIL PROTECTED]
Cc: Dave Airlie [EMAIL PROTECTED]; Keith Packard [EMAIL PROTECTED]; DRI
dri-devel@lists.sourceforge.net; Dave Airlie [EMAIL
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
http://bugzilla.kernel.org/show_bug.cgi?id=10681
--- Comment #2 from [EMAIL PROTECTED] 2008-05-14 13:37 ---
Oh, well. I'm screwed then... ;)
Two questions still haunt me by night, There actually was DRI support in the
2.4.x branch of the kernel? If so, Why it got broken?
Anyway, I
http://bugs.freedesktop.org/show_bug.cgi?id=14840
Jose Rodriguez [EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
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.
30 matches
Mail list logo
