From: Dave Airlie
Fix some warnings reported in linux-next + also cleanup some
comment errors noticed by Pekka Paalanen.
Signed-off-by: Dave Airlie
---
drivers/gpu/vga/vgaarb.c | 11 -
include/linux/vgaarb.h | 49 +
2 files changed, 32
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
http://bugs.freedesktop.org/show_bug.cgi?id=12385
--- Comment #10 from Andrew Randrianasulu 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 mail because: --
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
C
http://bugs.freedesktop.org/show_bug.cgi?id=21884
Bruno Pio changed:
What|Removed |Added
Resolution|FIXED |WORKSFORME
--- Comment #4 from Bruno Pio
http://bugs.freedesktop.org/show_bug.cgi?id=21884
Bruno Pio changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=21065
Eric Anholt changed:
What|Removed |Added
AssignedTo|dri-|e...@anholt.net
|de...@l
http://bugs.freedesktop.org/show_bug.cgi?id=12385
Eric Anholt changed:
What|Removed |Added
Keywords||NEEDINFO
--- Comment #9 from Eric Anhol
http://bugs.freedesktop.org/show_bug.cgi?id=22494
Eric Anholt changed:
What|Removed |Added
AssignedTo|dri-|i...@freedesktop.org
|de
http://bugs.freedesktop.org/show_bug.cgi?id=21884
Eric Anholt changed:
What|Removed |Added
Keywords||NEEDINFO
Summary|[945GM] "uxa"
http://bugs.freedesktop.org/show_bug.cgi?id=21693
Eric Anholt changed:
What|Removed |Added
AssignedTo|dri-|e...@anholt.net
|de...@l
http://bugs.freedesktop.org/show_bug.cgi?id=21530
Eric Anholt changed:
What|Removed |Added
AssignedTo|dri-|e...@anholt.net
|de...@l
http://bugs.freedesktop.org/show_bug.cgi?id=23250
Eric Anholt changed:
What|Removed |Added
AssignedTo|dri-|e...@anholt.net
|de...@l
http://bugs.freedesktop.org/show_bug.cgi?id=22309
Eric Anholt changed:
What|Removed |Added
AssignedTo|dri-|e...@anholt.net
|de...@l
http://bugs.freedesktop.org/show_bug.cgi?id=21416
Eric Anholt changed:
What|Removed |Added
AssignedTo|dri-|e...@anholt.net
|de...@l
http://bugzilla.kernel.org/show_bug.cgi?id=13713
--- Comment #11 from Eric Anholt 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
--- You are
On Tue, Aug 18, 2009 at 6:31 PM, Thomas Hellström 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 (struct_mutex vs
>
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 Wed, Aug 19, 2009 at 9:31 AM, Luc Verhaegen wrote:
> On Wed, Aug 19, 2009 at 09:22:10AM +1000, Dave Airlie wrote:
>> On Wed, Aug 19, 2009 at 9:12 AM, Luc Verhaegen wrote:
>> > On Wed, Aug 19, 2009 at 09:07:55AM +1000, Dave Airlie wrote:
>> >> On Wed, Aug 19, 2009 at 8:03 AM, Luc Verhaegen wrote:
On Wed, Aug 19, 2009 at 09:22:10AM +1000, Dave Airlie wrote:
> On Wed, Aug 19, 2009 at 9:12 AM, Luc Verhaegen wrote:
> > On Wed, Aug 19, 2009 at 09:07:55AM +1000, Dave Airlie wrote:
> >> On Wed, Aug 19, 2009 at 8:03 AM, Luc Verhaegen wrote:
> >> > On Wed, Aug 19, 2009 at 07:03:41AM +1000, Dave Airl
On Tue, Aug 18, 2009 at 7:12 PM, Luc Verhaegen 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:07:55AM +1000, Dave Airlie wrote:
> On Wed, Aug 19, 2009 at 8:03 AM, Luc Verhaegen wrote:
> > On Wed, Aug 19, 2009 at 07:03:41AM +1000, Dave Airlie wrote:
> >> On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell wrote:
> >> > I think the bug in question was because somebody (
On Wed, Aug 19, 2009 at 8:03 AM, Luc Verhaegen wrote:
> On Wed, Aug 19, 2009 at 07:03:41AM +1000, Dave Airlie wrote:
>> On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell wrote:
>> > I think the bug in question was because somebody (Jon Smirl??)
>> > removed the empty & apparently unused poll implemen
On Tue, Aug 18, 2009 at 6:12 PM, Thomas Hellström wrote:
> Kristian Høgsberg wrote:
>>
>> On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlie wrote:
>>
>>>
>>> On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell wrote:
>>>
I think the bug in question was because somebody (Jon Smirl??) removed
t
- 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
---
drivers/gpu/drm/drm_crtc_helper.c | 86 +++--
1 files changed, 54 insertions(+), 32 deletions(-)
di
- Previously the old encoder would be called during modeset and without a
connector bad things happened.
Signed-off-by: Maarten Maathuis
---
drivers/gpu/drm/drm_crtc_helper.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers
- The symbol was already exported.
Signed-off-by: Maarten Maathuis
---
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
--- a/include/drm/drm_crtc_hel
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
On Wed, Aug 19, 2009 at 07:03:41AM +1000, Dave Airlie wrote:
> On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell 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 s
Kristian Høgsberg wrote:
> On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlie wrote:
>
>> On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell wrote:
>>
>>> I think the bug in question was because somebody (Jon Smirl??) removed the
>>> empty & apparently unused poll implementation from the drm fd, on
On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlie wrote:
> On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell 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 ac
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwell 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 to, extends
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 Høg
On Tue, 18 Aug 2009 12:10:34 -0700
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 e
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 ensu
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 submit
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
On Tue, Aug 18, 2009 at 1:36 PM, Thomas Hellström wrote:
> Kristian Høgsberg wrote:
>>
>> On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellström
>> 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
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 cod
Kristian Høgsberg wrote:
> On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellström 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
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
On Tue, 18 Aug 2009 09:17:23 -0700
Jesse Barnes 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 believe s
On Tue, Aug 18, 2009 at 2:08 AM, Thomas Hellström 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 fd. How were
On Tue, Aug 18, 2009 at 11:51 AM, Pauli Nieminen 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
Acked-by: Alex
On Tue, Aug 18, 2009 at 11:51 AM, Pauli Nieminen wrote:
> GCC did war about optimization not possible because possible forever loop.
>
> Signed-off-by: Pauli Nieminen
Acked-by: Alex Deucher
> ---
> libdrm/radeon/radeon_cs_gem.c | 12 ++--
> 1 files changed, 6 insertions(+), 6 deletio
On Tue, 18 Aug 2009 16:24:14 +1000
Dave Airlie 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, 18 Aug 2009 08:08:24 +0200
Thomas Hellström wrote:
> Kristian Høgsberg wrote:
> > 2009/8/17 Thomas Hellström :
> >
> >> 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
On Tue, 18 Aug 2009 09:32:50 +0200
Thomas Hellström wrote:
> Jesse Barnes wrote:
> > On Mon, 17 Aug 2009 22:22:34 +0200
> > Thomas Hellström wrote:
> >
> >
> >> Kristian Høgsberg wrote:
> >>
> >>> This patch adds a vblank synced pageflip ioctl for to the
> >>> modesetting family of ioctl
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 s
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)
Statu
GCC did war about optimization not possible because possible forever loop.
Signed-off-by: Pauli Nieminen
---
libdrm/radeon/radeon_cs_gem.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libdrm/radeon/radeon_cs_gem.c b/libdrm/radeon/radeon_cs_gem.c
index 264b0
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
---
libdrm/radeon/radeon_cs.h |9 +
1 files changed, 9 insertions(+
On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellström 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 waiting.
>>
>> 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 lo
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
---
drivers/gpu
http://bugs.freedesktop.org/show_bug.cgi?id=22743
--- Comment #3 from Fabio 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 that index which
> i
The device directory will be the base directory of the
sysfs representation of other ttm subsystems.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_module.c | 58 +-
1 files changed, 57 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm
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 synchro
Kristian Høgsberg wrote:
> 2009/8/17 Thomas Hellström :
>
>> 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 vertical b
Jesse Barnes wrote:
> On Mon, 17 Aug 2009 22:22:34 +0200
> Thomas Hellström 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 fb
60 matches
Mail list logo
