On Sunday 29 November 2009 19:51:55 Robert Noland wrote:
> On Sun, 2009-11-29 at 15:36 -0800, vehemens wrote:
> > I believe that moving away from the current model makes it more
> > difficult
> > to "... spread the burden ...", hence my objections. If you want
On Sunday 29 November 2009 15:36:51 Adam K Kirchhoff wrote:
> On Sunday 29 November 2009 18:54:31 vehemens wrote:
> > On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote:
> > > On Sunday 29 November 2009 14:16:13 vehemens wrote:
> > >
> > > [snip]
>
On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote:
> On Sunday 29 November 2009 14:16:13 vehemens wrote:
>
> [snip]
>
> > Your missing the point of using a development structure which supports
> > collobration.
>
> [snip]
>
> > The difference is t
On Sunday 29 November 2009 10:39:34 Maarten Maathuis wrote:
> I enjoy playing the devils advocate occasionally, so take this with a
> grain of salt.
>
> My understanding is that there are roughly 3 bsd kernels that support
> drm userspace interface(free*, open* and netbsd?), each has 1 or 2
> maint
On Sunday 29 November 2009 07:07:41 Robert Noland wrote:
> On Sat, 2009-11-28 at 20:40 -0800, vehemens wrote:
> > On Saturday 28 November 2009 16:21:58 Robert Noland wrote:
> > > On Sat, 2009-11-28 at 13:38 -0800, vehemens wrote:
> > > > On Saturday 28 November 200
On Sunday 29 November 2009 00:31:17 Daniel Stone wrote:
> Hi,
>
> On Sat, Nov 28, 2009 at 08:40:55PM -0800, vehemens wrote:
> > On Saturday 28 November 2009 16:21:58 Robert Noland wrote:
> > > Because unpublished work doesn't exist That goes for the work that
&
On Saturday 28 November 2009 16:21:58 Robert Noland wrote:
> On Sat, 2009-11-28 at 13:38 -0800, vehemens wrote:
> > On Saturday 28 November 2009 10:41:39 Robert Noland wrote:
> > > On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote:
> > > > On Sunday 22 November 2
On Saturday 28 November 2009 13:44:53 Dave Airlie wrote:
> > I haven't published any of my work recently, but that doesn't mean I
> > haven't done anything that I would like to share. Not sure why you feel
> > this is important however.
> >
> > I gave you a number of suggestions in private emails
On Saturday 28 November 2009 10:41:39 Robert Noland wrote:
> On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote:
> > On Sunday 22 November 2009 01:01:10 Dave Airlie wrote:
> > > On Sun, Nov 22, 2009 at 7:10 PM, vehemens wrote:
> > > > On Saturday 21 November 2
On Sunday 22 November 2009 01:01:10 Dave Airlie wrote:
> On Sun, Nov 22, 2009 at 7:10 PM, vehemens wrote:
> > On Saturday 21 November 2009 20:09:53 Dave Airlie wrote:
> >> > I see that you deleted bsd-core dispite the requests of a number of
> >> > people t
On Saturday 21 November 2009 20:09:53 Dave Airlie wrote:
> > I see that you deleted bsd-core dispite the requests of a number of
> > people that you do not.
>
> Its git, nobody has touched any of it in ages, and none of the BSD
> maintainers used it, you can just get it back by branching from the c
On Friday 20 November 2009 14:20:41 Kristian Høgsberg wrote:
> 2009/11/19 Eric Anholt :
> > On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote:
> >> 2009/11/6 Kristian Høgsberg :
> >> > Hi,
> >> >
> >> > This has come up a few time and it's something I think makes a lot of
> >> > sense. Si
On Tuesday 17 November 2009 08:33:30 Kristian Høgsberg wrote:
> 2009/11/6 Kristian Høgsberg :
> > Hi,
> >
> > This has come up a few time and it's something I think makes a lot of
> > sense. Since all driver development (afaik) now happens in linux
> > kernel tree, it makes sense to drop the drive
On Sunday 29 March 2009 10:55:52 pm Alex Deucher wrote:
> New commits:
> commit c3c2ae466cfa1d4e079f6f0396e8f0f68ecb84b8
> Merge: 48b5f09... e2d7dfb...
> Author: Alex Deucher
> Date: Mon Mar 30 01:54:54 2009 -0400
>
> Merge branch 'master' into r6xx-r7xx-support
thank you
On Saturday 28 February 2009 05:28:38 am Pekka Paalanen wrote:
> On Fri, 27 Feb 2009 23:54:21 -0800
>
> vehemens wrote:
> > On Friday 27 February 2009 01:45:50 pm Kristian Høgsberg wrote:
> > > On Fri, Feb 27, 2009 at 4:40 PM, Dave Airlie wrote:
> > > > Promp
On Saturday 28 February 2009 09:06:38 am Robert C. Noland III wrote:
> On Fri, 2009-02-27 at 23:54 -0800, vehemens wrote:
> > On Friday 27 February 2009 01:45:50 pm Kristian Høgsberg wrote:
> > > On Fri, Feb 27, 2009 at 4:40 PM, Dave Airlie wrote:
> > > > Prompted by
On Friday 27 February 2009 01:45:50 pm Kristian Høgsberg wrote:
> On Fri, Feb 27, 2009 at 4:40 PM, Dave Airlie wrote:
> > Prompted by how well it worked with Intel, and changes in my personal
> > life leading to reduced time availability (except at 4am...) I'm going to
> > clarify the process for
On Friday 27 February 2009 01:40:25 pm Dave Airlie wrote:
> Prompted by how well it worked with Intel, and changes in my personal life
> leading to reduced time availability (except at 4am...) I'm going to
> clarify the process for getting patches upstream now. (a...@amd also
> trialed this to get
On Tuesday 17 February 2009 05:43:32 pm Robert C. Noland III wrote:
> On Mon, 2009-02-16 at 18:39 +, Owain Ainsworth wrote:
> > On Sat, Feb 14, 2009 at 11:24:18PM +0200, Pekka Paalanen wrote:
> > > >From 29d3f6e9c1258736c3199834b293b8128faef2ad Mon Sep 17 00:00:00 2001
> > >
> > > From: Pekka P
On Thursday 11 December 2008 04:28:48 pm Jesse Barnes wrote:
> On Thursday, December 11, 2008 4:16 pm vehemens wrote:
> > On Wednesday 10 December 2008 03:52:08 pm Jesse Barnes wrote:
> > >...
> > >New commits:
> > >commit 9583c099b4a08b49e03f7b461c344b
On Wednesday 10 December 2008 03:52:08 pm Jesse Barnes wrote:
>...
>New commits:
>commit 9583c099b4a08b49e03f7b461c344b6d277fd262
>Author: Jesse Barnes
>Date: Wed Dec 10 15:47:28 2008 -0800
>
>Revert "Merge branch 'modesetting-gem'"
>
>This reverts commit 6656db10551bbb8770dd945b6d81
Would anyone object to using a struct for the vblank crtc data to eliminate
the multiple allocs / frees?
For example:
struct drm_vblank {
wait_queue_head_t vbl_queue;
atomic_t _vblank_count;
struct drm_vbl_sig_list vbl_sigs;
atomic_t vblank_refcount;
u32 l
On Wednesday 28 May 2008 04:35:42 am Oleg Nauman wrote:
> On Wed, May 28, 2008 at 10:34 AM, vehemens <[EMAIL PROTECTED]> wrote:
> > Here are a few drm patches.
> >
> > correct another lock leak.
> >
> > add missing link.
> >
> > negate return va
Here are a few drm patches.
correct another lock leak.
add missing link.
negate return value. minor cleanup while we are here.
diff --git a/bsd-core/drm_bufs.c b/bsd-core/drm_bufs.c
index 3508331..c793634 100644
--- a/bsd-core/drm_bufs.c
+++ b/bsd-core/drm_bufs.c
@@ -832,12 +832,12 @@ int drm_
On Thursday 01 May 2008 07:16:36 am Jerome Glisse wrote:
> On Tue, 29 Apr 2008 20:51:45 -0700
>
> vehemens <[EMAIL PROTECTED]> wrote:
> > The primary goal is to update the BSD drm code with the recent linux
> > changes including linux drm memory management code. I haven
On Tuesday 29 April 2008 08:35:36 am Jerome Glisse wrote:
> On Mon, 28 Apr 2008 08:26:41 -0700
>
> vehemens <[EMAIL PROTECTED]> wrote:
> > I'm currently working on updating the bsd libdrm for use with my freebsd
> > system. To reduce the work involved, I&
I'm currently working on updating the bsd libdrm for use with my freebsd
system. To reduce the work involved, I'm using some code from the linux
kernel for lists and atomics. This also greatly reduces the amount of unique
code required.
Unfortunately I only have radeon rv370 and intel i810 class
I'm currently working on updating the bsd libdrm for use with my freebsd
system. To reduce the work involved, I'm using some code from the linux
kernel for lists and locks. This also greatly reduces the amount of unique
code required.
Unfortunately I only have radeon rv370 and intel i810 class h
On Monday 23 July 2007 07:59:24 am Eric Anholt wrote:
> This was used to make all ioctl handlers return -errno on linux and
> errno on *BSD. Instead, just return -errno in shared code, and flip sign
> on return from shared code to *BSD code.
I was trying to determine why my system hung and fo
Isn't DRM_ERR() required for compatibility?
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Dow
On Monday 09 July 2007 02:51:37 am Michel Dänzer wrote:
> On Mon, 2007-07-09 at 00:38 -0700, vehemens wrote:
> > I believe I have narrowed the problem down to __glXDRIscreenProbe()
> > removing the RADEON DRM lock that was set up with DRIFinishScreenInit().
> >
>
On Saturday 23 December 2006 14:23, Jerome Glisse wrote:
> On 12/23/06, Magnus Ahlberg <[EMAIL PROTECTED]> wrote:
> > I know that there has been some discussion about the r500 chip and how
> > tough it will be to create a working driver for it. However, I for one
> > would love to see an open alter
Posting my latest DRM and Mesa patches in case they should prove useful to
anyone else. They are to head as of early Saturday.
I moved the CP idle outside the while loop in radeon_state.c. I think it may
apply to the R300 as well as there is an "if R300 idle command" in the
Xserver RADEONEnte
On Monday 28 November 2005 02:55 pm, Benjamin Herrenschmidt wrote:
> The DRM lock should protect that ... note that I just spotted a DRM fix
> "drm: fix quiescent locking" going into the linux kernel that may
> explain races with the DRM lock.
>
> Also, there has been historical issues with the scr
On Monday 28 November 2005 02:55 pm, Benjamin Herrenschmidt wrote:
> On Mon, 2005-11-28 at 02:18 -0800, vehemens wrote:
> > I've been looking at my remaining lockups, and find that I keep coming
> > back to the use of scratch registers in the driver for one of them.
> >
&
I've been looking at my remaining lockups, and find that I keep coming back to
the use of scratch registers in the driver for one of them.
If I'm reading the code correctly, the scratch registers are per device, not
per client. This would mean that you can't run more then one client without
t
It took over an hour this time, but it locked up while running three different
demos.
> Looks good.. but dude diff -u plz
>
> I can't read context diffs to save my life...
>
> Dave.
Done.
drmbld/shared-core/radeon_state.c
--- drm111605/shared-core/radeon_state.cFri Nov 11 20:25:43 2
I appear to of eliminated my remaining lockups by also idling the 2D engine in
radeon_cp_indirect which is being called from the xserver. Here is my latest
patch.
*** drm111605/shared-core/radeon_state.cFri Nov 11 20:25:43 2005
--- drmbld/shared-core/radeon_state.c Wed Nov 23 22:15:17
I've managed to eliminate a number of lockups when running one or more copies
of glxgears and other GL programs with the patch below.
This suggests that the driver needs some type of command timing/processing
rules to prevent lockup (NOPs?).
I working on the other lockups, but debug seems to fi
39 matches
Mail list logo