Kristian Høgsberg wrote:
2009/8/17 Thomas Hellström tho...@shipmail.org:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming
+#undef set_base
+
struct drm_prop_enum_list {
int type;
char *name;
@@ -342,6 +344,34 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
EXPORT_SYMBOL(drm_framebuffer_cleanup);
/**
+ * drm_crtc_async_flip - do a set_base call from a work queue
+ * @work: work
Jesse Barnes wrote:
On Mon, 17 Aug 2009 22:22:34 +0200
Thomas Hellström tho...@shipmail.org wrote:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the
modesetting family of ioctls. The ioctl takes a crtc and an fb and
schedules a pageflip to the new
Kristian Høgsberg wrote:
2009/8/17 Thomas Hellström tho...@shipmail.org:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming
Hi all,
I try to use the vertical synchronization on a program which use the functions
of openGL (glXWaitVideoSyncSGI), but the driver drm.ko does a wait
(DRM_WAIT_ON, function : drm_wait_vblank, file : drm_irq.c) on the crtc 0 and
does a wake up (DRM_WAKEUP) on the crtc 1 so, I haven't
The device directory will be the base directory of the
sysfs representation of other ttm subsystems.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ttm/ttm_module.c | 58 +-
1 files changed, 57 insertions(+), 1 deletions(-)
diff
http://bugs.freedesktop.org/show_bug.cgi?id=22743
--- Comment #3 from Fabio fabio@libero.it 2009-08-18 01:45:38 PST ---
(In reply to comment #2)
This is a nexuiz bug and should be fixed there (if it isn't already, I didn't
test latest version). Note that nexuiz doesn't actually use
Common resources, like memory accounting and swap lists should be
global and not per device. Introduce a struct ttm_bo_global to
accomodate this, and register it with sysfs. Add a small sysfs interface
to return the number of active buffer objects.
Signed-off-by: Thomas Hellstrom
I'm a little fuzzy on the details, this part of the patch was carried
over from Jesse's original work. I believe set_base is supposed to be
called with the struct mutex held.
We shouldn't be this sloppy about locking, and in particular we shouldn't
protect a callback with a lock without
On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellströmtho...@shipmail.org wrote:
Kristian Høgsberg wrote:
By sending an event back on the file descriptor we allow users of the
API to wait on the flip to finish in a standard poll or select
mainloop, where it can handle input from other sources while
Using this call in OUT_BATCH_TABLE reduces radeonEmitState cpu usage from
9% to 5% and emit_vpu goes from 7% to 1.5%. I did use calgrind to profile
gears for cpu hotspots with r500 card.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
libdrm/radeon/radeon_cs.h |9 +
1 files
GCC did war about optimization not possible because possible forever loop.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
libdrm/radeon/radeon_cs_gem.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libdrm/radeon/radeon_cs_gem.c
http://bugs.freedesktop.org/show_bug.cgi?id=23393
Summary: Qt apps started with --graphicssystem opengl crash
with KMS on radeon
Product: DRI
Version: DRI CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
I think the bug in question was because somebody (Jon Smirl??) removed the
empty apparently unused poll implementation from the drm fd, only to discover
that the X server was actually polling the fd.
If this code adds to, extends or at least doesn't remove the ability to poll
the drm fd, it
On Tue, 18 Aug 2009 09:32:50 +0200
Thomas Hellström tho...@shipmail.org wrote:
Jesse Barnes wrote:
On Mon, 17 Aug 2009 22:22:34 +0200
Thomas Hellström tho...@shipmail.org wrote:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the
modesetting
On Tue, 18 Aug 2009 08:08:24 +0200
Thomas Hellström tho...@shipmail.org wrote:
Kristian Høgsberg wrote:
2009/8/17 Thomas Hellström tho...@shipmail.org:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the
modesetting family of ioctls. The ioctl
On Tue, 18 Aug 2009 16:24:14 +1000
Dave Airlie airl...@gmail.com wrote:
+#undef set_base
+
struct drm_prop_enum_list {
int type;
char *name;
@@ -342,6 +344,34 @@ void drm_framebuffer_cleanup(struct
drm_framebuffer *fb) EXPORT_SYMBOL(drm_framebuffer_cleanup);
/**
On Tue, Aug 18, 2009 at 11:51 AM, Pauli Nieminensuok...@gmail.com wrote:
GCC did war about optimization not possible because possible forever loop.
Signed-off-by: Pauli Nieminen suok...@gmail.com
Acked-by: Alex Deucher alexdeuc...@gmail.com
---
libdrm/radeon/radeon_cs_gem.c | 12
On Tue, Aug 18, 2009 at 11:51 AM, Pauli Nieminensuok...@gmail.com wrote:
Using this call in OUT_BATCH_TABLE reduces radeonEmitState cpu usage from
9% to 5% and emit_vpu goes from 7% to 1.5%. I did use calgrind to profile
gears for cpu hotspots with r500 card.
Signed-off-by: Pauli Nieminen
On Tue, Aug 18, 2009 at 2:08 AM, Thomas Hellströmtho...@shipmail.org wrote:
Kristian Høgsberg wrote:
Perhaps TTM bo read/write could use ioctls like the gem pwrite/pread
ioctls? The only way we can get asynchronous notifications from the
drm to userspace is through readable events on the drm
On Tue, 18 Aug 2009 09:17:23 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
Exactly what in the generic modesetting code is protected by the
struct mutex here?
I'm a little fuzzy on the details, this part of the patch was
carried over from Jesse's original work. I
Hi!
Idea is to not to block client application when it request buffer swap. This
should give small performance gains when swap buffer is synchronised to
vblank.
I can think of 3 different implementations to archive this continues
execution of client.
First one is to just allocate 2 back buffers
Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellströmtho...@shipmail.org wrote:
Kristian Høgsberg wrote:
By sending an event back on the file descriptor we allow users of the
API to wait on the flip to finish in a standard poll or select
mainloop, where it can
No objections?
Maarten.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application
On Tue, Aug 18, 2009 at 1:36 PM, Thomas Hellströmtho...@shipmail.org wrote:
Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellströmtho...@shipmail.org
wrote:
Kristian Høgsberg wrote:
By sending an event back on the file descriptor we allow users of the
API to wait on
This seems wrong to me -- the client doesn't need to sleep - all it's going to
do is build a command buffer targeting the new backbuffer. There's no problem
with that, it should be the preserve of the GPU scheduler (TTM or GEM) to
ensure those commands (once submitted) don't get executed until
Keith Whitwell wrote:
This seems wrong to me -- the client doesn't need to sleep - all it's going
to do is build a command buffer targeting the new backbuffer. There's no
problem with that, it should be the preserve of the GPU scheduler (TTM or
GEM) to ensure those commands (once
Thomas Hellström wrote:
Keith Whitwell wrote:
This seems wrong to me -- the client doesn't need to sleep - all it's
going to do is build a command buffer targeting the new backbuffer.
There's no problem with that, it should be the preserve of the GPU
scheduler (TTM or GEM) to ensure those
On Tue, 18 Aug 2009 12:10:34 -0700
Keith Whitwell kei...@vmware.com wrote:
This seems wrong to me -- the client doesn't need to sleep - all it's
going to do is build a command buffer targeting the new backbuffer.
There's no problem with that, it should be the preserve of the GPU
scheduler
No, I'm fine. I don't have the patch in front of me but it doesn't sound like
it precludes these types of changes in the future.
Keith
From: Jesse Barnes [jbar...@virtuousgeek.org]
Sent: Tuesday, August 18, 2009 1:23 PM
To: Keith Whitwell
Cc: Kristian
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
I think the bug in question was because somebody (Jon Smirl??) removed the
empty apparently unused poll implementation from the drm fd, only to
discover that the X server was actually polling the fd.
If this code adds
On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlieairl...@gmail.com wrote:
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
I think the bug in question was because somebody (Jon Smirl??) removed the
empty apparently unused poll implementation from the drm fd, only to
Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlieairl...@gmail.com wrote:
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
I think the bug in question was because somebody (Jon Smirl??) removed the
empty apparently unused poll
On Wed, Aug 19, 2009 at 07:03:41AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
I think the bug in question was because somebody (Jon Smirl??)
removed the empty apparently unused poll implementation from the
drm fd, only to discover
Jesse Barnes wrote:
Anyway, to me this discussion is more of a future directions one than
a blocker for this particular patchset. AFAICT the only thing that
needs fixing with this patch is my lock confusion (struct_mutex vs
mode_config). Or would you like something substantial changed with
- The symbol was already exported.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
include/drm/drm_crtc_helper.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 6769ff6..e44a4f8 100644
---
- Previously the old encoder would be called during modeset and without a
connector bad things happened.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/drm_crtc_helper.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git
- The previous system was not very transparent, nor flexible.
- This is needed to be able to fix a few bugs in the mechanism.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/drm_crtc_helper.c | 86 +++--
1 files changed, 54
On Tue, Aug 18, 2009 at 6:12 PM, Thomas Hellströmtho...@shipmail.org wrote:
Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlieairl...@gmail.com wrote:
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
I think the bug in question was because
On Wed, Aug 19, 2009 at 8:03 AM, Luc Verhaegenl...@skynet.be wrote:
On Wed, Aug 19, 2009 at 07:03:41AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
I think the bug in question was because somebody (Jon Smirl??)
removed the empty
On Wed, Aug 19, 2009 at 09:07:55AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 8:03 AM, Luc Verhaegenl...@skynet.be wrote:
On Wed, Aug 19, 2009 at 07:03:41AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
I think the bug in question
On Tue, Aug 18, 2009 at 7:12 PM, Luc Verhaegenl...@skynet.be wrote:
And on the flip side of this, what you do is purely technical, always.
#dri-devel 00:05 +airlied krh: you've been smirled
Yeah, I was wondering about that, I thought the word was smirl-rolled :D
cheers,
Kristian
On Wed, Aug 19, 2009 at 09:22:10AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 9:12 AM, Luc Verhaegenl...@skynet.be wrote:
On Wed, Aug 19, 2009 at 09:07:55AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 8:03 AM, Luc Verhaegenl...@skynet.be wrote:
On Wed, Aug 19, 2009 at
On Wed, Aug 19, 2009 at 9:31 AM, Luc Verhaegenl...@skynet.be wrote:
On Wed, Aug 19, 2009 at 09:22:10AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 9:12 AM, Luc Verhaegenl...@skynet.be wrote:
On Wed, Aug 19, 2009 at 09:07:55AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 8:03 AM,
On Wed, Aug 19, 2009 at 01:31:06AM +0200, Luc Verhaegen wrote:
Dave,
Ask yourself whether your statement, the one i replied to, was a
technical contribution, or something else?
Luc,
Just ... stop. This is embarassing.
Daniel
pgp6apJk0Gjf4.pgp
Description: PGP signature
On Tue, Aug 18, 2009 at 6:31 PM, Thomas Hellströmtho...@shipmail.org wrote:
Jesse Barnes wrote:
Anyway, to me this discussion is more of a future directions one than
a blocker for this particular patchset. AFAICT the only thing that
needs fixing with this patch is my lock confusion
http://bugzilla.kernel.org/show_bug.cgi?id=13713
--- Comment #11 from Eric Anholt e...@anholt.net 2009-08-19 00:56:21 ---
The kernel bugzilla is the wrong place to be tracking a Mesa bug.
(Yes, this should be closed)
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
http://bugs.freedesktop.org/show_bug.cgi?id=21416
Eric Anholt e...@anholt.net changed:
What|Removed |Added
AssignedTo|dri-|e...@anholt.net
http://bugs.freedesktop.org/show_bug.cgi?id=22309
Eric Anholt e...@anholt.net changed:
What|Removed |Added
AssignedTo|dri-|e...@anholt.net
http://bugs.freedesktop.org/show_bug.cgi?id=23250
Eric Anholt e...@anholt.net changed:
What|Removed |Added
AssignedTo|dri-|e...@anholt.net
http://bugs.freedesktop.org/show_bug.cgi?id=21530
Eric Anholt e...@anholt.net changed:
What|Removed |Added
AssignedTo|dri-|e...@anholt.net
http://bugs.freedesktop.org/show_bug.cgi?id=21693
Eric Anholt e...@anholt.net changed:
What|Removed |Added
AssignedTo|dri-|e...@anholt.net
http://bugs.freedesktop.org/show_bug.cgi?id=21884
Eric Anholt e...@anholt.net changed:
What|Removed |Added
Keywords||NEEDINFO
http://bugs.freedesktop.org/show_bug.cgi?id=22494
Eric Anholt e...@anholt.net changed:
What|Removed |Added
AssignedTo|dri-|i...@freedesktop.org
http://bugs.freedesktop.org/show_bug.cgi?id=12385
Eric Anholt e...@anholt.net changed:
What|Removed |Added
Keywords||NEEDINFO
--- Comment #9
http://bugs.freedesktop.org/show_bug.cgi?id=21065
Eric Anholt e...@anholt.net changed:
What|Removed |Added
AssignedTo|dri-|e...@anholt.net
http://bugs.freedesktop.org/show_bug.cgi?id=21884
Bruno Pio brunopi...@yahoo.com.br changed:
What|Removed |Added
Resolution|FIXED |WORKSFORME
---
http://bugs.freedesktop.org/show_bug.cgi?id=23402
Summary: Latest CVS leads to crash in sauerbraten
Product: Mesa
Version: CVS
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
http://bugs.freedesktop.org/show_bug.cgi?id=12385
--- Comment #10 from Andrew Randrianasulu rand...@mail.ru 2009-08-18
21:08:47 PST ---
Sorry, I don't have this hardware anymore ...
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this
Hi Linus,
Please pull the 'drm-fixes' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes
two non-staging kms fixes in this, one for a possible oops when destroying
a framebuffer, one for reading EDID incorrectly on some monitors.
Some staging radeon kms
From: Dave Airlie airl...@linux.ie
Fix some warnings reported in linux-next + also cleanup some
comment errors noticed by Pekka Paalanen.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/vga/vgaarb.c | 11 -
include/linux/vgaarb.h | 49
61 matches
Mail list logo
