Re: Move lists to freedesktop.org?

2010-04-09 Thread Stephane Marchesin
On Thu, Apr 8, 2010 at 16:37, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 8 Apr 2010 18:38:03 -0400 Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Apr 8, 2010 at 6:21 PM, Brian Paul bri...@vmware.com wrote: Unless there's some objection I'm going to subscribe everyone to the

Re: [git pull] drm request 3

2010-03-05 Thread Stephane Marchesin
On Thu, Mar 4, 2010 at 23:44, Ingo Molnar mi...@elte.hu wrote: * Pekka Enberg penb...@cs.helsinki.fi wrote: On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar mi...@elte.hu wrote: The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: ?- wrong ?- harmful

Re: [git pull] drm request 3

2010-03-04 Thread Stephane Marchesin
On Thu, Mar 4, 2010 at 12:07, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Matthew Garrett wrote: IOW, we have a real technical problem here. Are you just going to continue to make excuses about it? I'm not questioning the fact that it would be preferable to

Re: [git pull] drm request 3

2010-03-04 Thread Stephane Marchesin
On Thu, Mar 4, 2010 at 15:03, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Adam Jackson wrote: On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: On Thu, 4 Mar 2010, Matthew Garrett wrote: If you'd made it clear that you wanted the interface to be stable

Re: [Mesa3d-dev] Move lists to freedesktop.org?

2010-03-04 Thread Stephane Marchesin
On Thu, Mar 4, 2010 at 15:09, Brian Paul bri...@vmware.com wrote: Jesse Barnes wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that

Re: 3D OpenGL applications eat CPU ressources

2010-02-07 Thread Stephane Marchesin
On Sat, Feb 6, 2010 at 11:47, Émeric Maschino emeric.masch...@gmail.com wrote: 2010/2/4 Jerome Glisse gli...@freedesktop.org: IIRC old radeon drm doesn't have any thing to dump GPU command stream. Look at http://www.x.org/docs/AMD/R5xx_Acceleration_v1.4.pdf to see what radeon GPU stream

Re: 3D OpenGL applications eat CPU ressources

2010-02-03 Thread Stephane Marchesin
On Tue, Feb 2, 2010 at 13:19, Émeric Maschino emeric.masch...@gmail.com wrote: 2010/2/1 Stephane Marchesin stephane.marche...@gmail.com: If an ia64 machine lockups, it will usually store an MCA telling you about why it locked/where in the code this happened. This is how I got ia64 DRI going

Re: 3D OpenGL applications eat CPU ressources

2010-02-01 Thread Stephane Marchesin
On Mon, Feb 1, 2010 at 13:17, Émeric Maschino emeric.masch...@gmail.com wrote: 2010/1/31 Jerome Glisse gli...@freedesktop.org: snip Eventually, strace log is flooded with ioctl(4, 0xc0106451, 0x6fd530f8) = 0 roughly at the time the CPU charge increases. This is consistent with what

Re: [git pull] drm

2009-12-11 Thread Stephane Marchesin
On Fri, Dec 11, 2009 at 00:58, Alan Cox a...@lxorguk.ukuu.org.uk wrote: But not only is Fedora not following the rules, You changed the rules. You require a Signed-off-by:. Fedora can no more add a signed off by than you can. It's not their code nor Red Hat's code any more than they own the

Re: [git pull] drm nouveau pony for Xmas.

2009-12-11 Thread Stephane Marchesin
2009/12/12 Dave Airlie airl...@gmail.com: 2009/12/12 Stephane Marchesin stephane.marche...@gmail.com: I did git log on the nouveau kernel tree nouveau dir with sort and uniq, I'm not sure where else I needed to trawl to get anymore ppl who have contributed to the KMS driver. I'm sure ppl

Re: [git pull] drm nouveau pony for Xmas.

2009-12-11 Thread Stephane Marchesin
On Sat, Dec 12, 2009 at 00:27, Stephane Marchesin stephane.marche...@gmail.com wrote: 2009/12/12 Dave Airlie airl...@gmail.com: 2009/12/12 Stephane Marchesin stephane.marche...@gmail.com: I did git log on the nouveau kernel tree nouveau dir with sort and uniq, I'm not sure where else I needed

Re: [git pull] drm nouveau pony for Xmas.

2009-12-11 Thread Stephane Marchesin
   along with project founder Stephane Marchesin marche...@icps.u-strasbg.fr Btw could we get proper developer credit here? I think 3/4 of the people who wrote the code are missing here. Stephane -- Return on Information

Re: [git pull] drm

2009-12-10 Thread Stephane Marchesin
On Thu, Dec 10, 2009 at 19:42, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 10 Dec 2009, Maarten Maathuis wrote: You assume that Red Hat has full control over the project, which i don't think is the case. The reason it isn't in staging yet (as far as i know) is because of

Re: [git pull] drm

2009-12-10 Thread Stephane Marchesin
2009/12/10 Alan Cox a...@lxorguk.ukuu.org.uk: The big question is what we call ctxprogs: binary blobs that are clearly executable, running somewhere in the GPU. No-one seems to know, if those are copyrightable, or if they can be redistributed. In their current form, they have been recorded

Re: RFC: libdrm repo

2009-11-17 Thread Stephane Marchesin
2009/11/17 Kristian Høgsberg k...@bitplanet.net: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: 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 driver bits

Re: RFC: libdrm repo

2009-11-17 Thread Stephane Marchesin
[oops, with reply-all this time] On Tue, Nov 17, 2009 at 18:07, Jesse Barnes jbar...@virtuousgeek.org wrote: On Mon, 9 Nov 2009 17:46:44 +0100 Stephane Marchesin marche...@icps.u-strasbg.fr wrote: And how do I get releases of libdrm out outside of kernel releases? We're doing libdrms

Re: RFC: libdrm repo

2009-11-09 Thread Stephane Marchesin
On Mon, Nov 9, 2009 at 11:51, Rémi Cardona r...@gentoo.org wrote: Le 09/11/2009 00:14, Robert Noland a écrit : There are any number of changes that may occur in libdrm that do not impact the KBI and users should be able to get those features/bug fixes without needing a new kernel.

Re: RFC: libdrm repo

2009-11-09 Thread Stephane Marchesin
On Mon, Nov 9, 2009 at 17:42, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 23:40 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 23:33, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 20:02, Eric

Re: RFC: libdrm repo

2009-11-08 Thread Stephane Marchesin
2009/11/6 Kristian Høgsberg k...@bitplanet.net: 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 driver bits from the drm.git repo.  I've put up a repo under

Re: RFC: libdrm repo

2009-11-08 Thread Stephane Marchesin
On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense.  Since all driver development

Re: RFC: libdrm repo

2009-11-08 Thread Stephane Marchesin
On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k

Re: RFC: libdrm repo

2009-11-08 Thread Stephane Marchesin
On Sun, Nov 8, 2009 at 23:33, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric

Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2

2009-09-01 Thread Stephane Marchesin
2009/9/1 Keith Whitwell kei...@vmware.com: On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote: Stephane Marchesin wrote: 2009/8/31 Thomas Hellström tho...@shipmail.org: The problem I see with Xv-API-in-kernel is that of the various hw constrains on the buffer layout. IMHO

Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2

2009-08-31 Thread Stephane Marchesin
2009/8/31 Thomas Hellström tho...@shipmail.org: Daniel Vetter wrote: ... In conclusion I don't think a common ioctl is worth it. But sharing some code and infrastructure on the kernel side is certainly possible, if someone implements overlay support for another chipset. But I don't really

Re: [PATCH 6/6] [drm/i915] implement drmmode overlay support v2

2009-08-31 Thread Stephane Marchesin
2009/8/31 Thomas Hellström tho...@shipmail.org: The problem I see with Xv-API-in-kernel is that of the various hw constrains on the buffer layout. IMHO this has two solutions: a) complicated to communicate the constrains to userspace. This is either to generic or not suitable for everything.

Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream

2009-07-20 Thread Stephane Marchesin
You obviously got all this completely wrong. I avoid writing closed source drivers whenever I can, I'm not whining and I'm not trying to push any of them. The code VIA is trying to submit has not been written by me nor anybody I know. All VIA code I and the companies I've worked for has

Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream

2009-07-20 Thread Stephane Marchesin
2009/7/20 Thomas Hellström tho...@shipmail.org: Stephane, Some comments on how these things has been handled / could be handled. I would like to raise a couple of real-life issues I have in mind: * First example, let's say VIA gets their Chrome9 DRM merged into the kernel. Now let's say I

Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream

2009-07-17 Thread Stephane Marchesin
On Fri, Jul 17, 2009 at 15:23, Keith Whitwellkei...@vmware.com wrote: Maybe VIA can provide some userspace code without putting together an entire driver. A handful of standalone programs that exercise the interface would help evaluate the interfaces and might be sufficient to serve as

Re: [RFC][PATCH] drm/radeon/kms: add initial colortiling support.

2009-06-25 Thread Stephane Marchesin
On Thu, Jun 25, 2009 at 09:46, Jerome Glissegli...@freedesktop.org wrote: On Wed, 2009-06-24 at 22:32 +0200, Roland Scheidegger wrote: On 24.06.2009 20:17, Jerome Glisse wrote: I think we should let user ask at gem map ioctl time if userspace wants an surface backed mapping or not, and gem

Re: [PATCH] drm: Round size of mappings in drmAddMap ioctl

2009-05-17 Thread Stephane Marchesin
On Mon, May 18, 2009 at 03:11, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Currently, userspace fails to obtain the SAREA mapping on some platforms because they pass SAREA_MAX to drmAddMap without aligning it to the page size. This breaks for example on PowerPC with 64K pages. The

Re: [PATCH 1/3] mga: Use request_firmware() to load microcode

2009-02-22 Thread Stephane Marchesin
Hi, This mga patch replaces a firmware that was split in pieces by functionality and that had comments with a single blob. So IMO it's actually decreasing the quality of the code. Stephane -- Open Source Business

Re: r200 lockup in radeon_cp_texture/radeon_freelist_get

2009-02-19 Thread Stephane Marchesin
On Thu, Feb 19, 2009 at 15:46, Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Feb 19, 2009 at 7:26 AM, Roland Scheidegger srol...@tungstengraphics.com wrote: On 19.02.2009 12:23, Arkadi Shishlov wrote: Roland Scheidegger wrote: I suspect you're hitting a r200 asic bug, which isn't present

Re: Removing nv from drm git

2009-02-04 Thread Stephane Marchesin
On Thu, Jan 29, 2009 at 09:40, Thomas Hellström tho...@shipmail.org wrote: Owain Ainsworth wrote: On Thu, Jan 29, 2009 at 12:04:22AM +0100, Stephane Marchesin wrote: Hi, If no one objects, I'll prune the nv kernel module from drm git sometime next week. Please do. Done. I'm wondering

Re: Removing nv from drm git

2009-02-04 Thread Stephane Marchesin
On Wed, Feb 4, 2009 at 11:14, Thomas Hellström tho...@shipmail.org wrote: Stephane Marchesin wrote: On Thu, Jan 29, 2009 at 09:40, Thomas Hellström tho...@shipmail.org wrote: Owain Ainsworth wrote: On Thu, Jan 29, 2009 at 12:04:22AM +0100, Stephane Marchesin wrote: Hi, If no one objects

Removing nv from drm git

2009-01-28 Thread Stephane Marchesin
Hi, If no one objects, I'll prune the nv kernel module from drm git sometime next week. Stephane -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story.

Re: Removing nv from drm git

2009-01-28 Thread Stephane Marchesin
On Thu, Jan 29, 2009 at 02:29, Owain Ainsworth zer...@googlemail.com wrote: On Thu, Jan 29, 2009 at 12:04:22AM +0100, Stephane Marchesin wrote: Hi, If no one objects, I'll prune the nv kernel module from drm git sometime next week. Please do. I'm wondering if we should prune i915 now

Nouveau merged into gallium-0.2

2008-11-13 Thread Stephane Marchesin
Hi, As you might have noticed, nouveau's gallium work has been merged into mesa's gallium-0.2 (yeah I slacked long enough on that). So now nouveau development should happen there (mesa/gallium-0.2). Mesa also gains g3dvl, which is Younes's summer of code work on implementing video decoding on top

Re: [RFC] remove DRM IRQ installation funcs

2008-08-26 Thread Stephane Marchesin
On Tue, Aug 26, 2008 at 8:57 PM, Jesse Barnes [EMAIL PROTECTED] wrote: The DRM design includes ioctls to allow a userland driver to tell the kernel driver when to register its interrupt handler and on what IRQ. This is a really bad idea for several reasons, and fortunately I don't think any

Re: [RFC] remove DRM IRQ installation funcs

2008-08-26 Thread Stephane Marchesin
On Tue, Aug 26, 2008 at 9:36 PM, Jesse Barnes [EMAIL PROTECTED] wrote: On Tuesday, August 26, 2008 12:03 pm Stephane Marchesin wrote: On Tue, Aug 26, 2008 at 8:57 PM, Jesse Barnes [EMAIL PROTECTED] wrote: The DRM design includes ioctls to allow a userland driver to tell the kernel driver

Re: [RFC] remove DRM IRQ installation funcs

2008-08-26 Thread Stephane Marchesin
On Tue, Aug 26, 2008 at 10:21 PM, Jesse Barnes [EMAIL PROTECTED] wrote: On Tuesday, August 26, 2008 1:03 pm Stephane Marchesin wrote: As for the new development model... Things are actually worse than I thought. There are some fairly large differences between linux-core and upstream, some

Re: DRM development process

2008-08-26 Thread Stephane Marchesin
On Tue, Aug 26, 2008 at 11:17 PM, Jesse Barnes [EMAIL PROTECTED] wrote: On Tuesday, August 26, 2008 1:27 pm Stephane Marchesin wrote: I am outlining the fact that you confuse a problem and its solution. Problem: merging stuff upstream takes time to Dave Your solution: have lots

Re: [PATCH 1/1] Adapt on_each_cpu

2008-08-10 Thread Stephane Marchesin
On 8/2/08, Jerome Glisse [EMAIL PROTECTED] wrote: I might be totaly wrong so feel free to ignore these. I got the feeling that the user test base on linux kernel is far bigger than ours. Also i think that our test user base are people wanting lastest things with old kernel, while i

Re: cursor handling and updates inside DRM

2008-07-10 Thread Stephane Marchesin
On Fri, Jul 11, 2008 at 1:12 AM, Tiago Vignatti [EMAIL PROTECTED] wrote: Hi Jakob, Jakob Bornecrantz escreveu: The only thing that should be in the kernel is the: - touch the gfx registers. and in some regards - takes care of the cursor limits. Anything else is the client

Re: radeon r6xx DRM...

2008-06-04 Thread Stephane Marchesin
If the new driver won't be an incremental change to the existing radeon drivers, I'd recommend basing it on Gallium. Hi Brian, It seems like people are mostly concerned about gallium stability right now. How stable wioll the interfaces be in the future ? Maybe if you could tell us, that'd

Re: TTM vs GEM discussion questions

2008-05-18 Thread Stephane Marchesin
On 5/16/08, Pekka Paalanen [EMAIL PROTECTED] wrote: On Fri, 16 May 2008 10:05:18 +0200 Jerome Glisse [EMAIL PROTECTED] wrote: My current understanding is that on newer GPU each client got its own memory address space on the GPU. I can manage this space transparently based on hint from

Re: TTM vs GEM discussion questions

2008-05-18 Thread Stephane Marchesin
On 5/18/08, Thomas Hellström [EMAIL PROTECTED] wrote: Yes, that was really my point. If the memory manager we use (whatever it is) does not allow this kind of behaviour, that'll force all cards to use a kernel-validated command submission model, which might not be too fast, and more

Re: TTM merging?

2008-05-18 Thread Stephane Marchesin
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...

Re: TTM merging?

2008-05-13 Thread Stephane Marchesin
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

Re: Gallium: Fix for tgsi_emit_sse2()

2008-04-02 Thread Stephane Marchesin
So, we should really fix this. The two options are : - Keep a different calling convention under linux (cdecl by default, which requires saving esi by hand in the shader) and apply Victor's patch which saves restores this register - Use the same calling convention on all platforms, that is change

Re: DRI Summer of Code ?

2008-03-12 Thread Stephane Marchesin
Ok, the DRI application for summer of code just went in (at the very last minute). Thanks to those who joined in and filled our project page, and hopefully talk to you when discussing projects :) Stephane - This SF.net email

Re: DRI Summer of Code ?

2008-03-10 Thread Stephane Marchesin
Ok, anyone else interested (ATM it's Jerome - Idr - Alex - me) ? The deadline for project applications is wednesday so we'll have to write the proposal for DRI quick now. Hopefully it works out. Stephane - This SF.net email

Re: DRI Summer of Code ?

2008-03-10 Thread Stephane Marchesin
On 3/11/08, Ian Romanick [EMAIL PROTECTED] wrote: Link missing in previous post: http://dri.freedesktop.org/wiki/GSoC_2008 I added a couple of ideas to the page. Who's next ? :) Stephane - This SF.net email is

DRI Summer of Code ?

2008-03-02 Thread Stephane Marchesin
Hi, I often hear DRI developers talking about how we lack contributors. Well, this is the occasion, I think we could get together and try to propose DRI as a separate organization for the google summer of code (it's also good to have DRI seen as a separate project from the outside, and not just

Re: redesigning the DRM internal logic..

2008-02-13 Thread Stephane Marchesin
On 2/13/08, Dave Airlie [EMAIL PROTECTED] wrote: So I've been thinking about this stuff a lot lately wrt to getting the DRM into a state that enables fast-user-switching, GPGPU apps, different users on a per head one a single card.. http://dri.freedesktop.org/wiki/DRMRedesign has a nice

Re: redesigning the DRM internal logic..

2008-02-13 Thread Stephane Marchesin
On 2/13/08, Jesse Barnes [EMAIL PROTECTED] wrote: On Wednesday, February 13, 2008 2:22 pm Stephane Marchesin wrote: On 2/13/08, Dave Airlie [EMAIL PROTECTED] wrote: So I've been thinking about this stuff a lot lately wrt to getting the DRM into a state that enables fast-user-switching

Re: redesigning the DRM internal logic..

2008-02-13 Thread Stephane Marchesin
On 2/14/08, Jesse Barnes [EMAIL PROTECTED] wrote: On Wednesday, February 13, 2008 3:55 pm Stephane Marchesin wrote: You don't want any application to be able to change CRTC-output mappings, or bind BOs to CRTCs. Ideally you'd just have one app that could do that on a given system

Re: redesigning the DRM internal logic..

2008-02-13 Thread Stephane Marchesin
On 2/14/08, Stephane Marchesin [EMAIL PROTECTED] wrote: I don't know if it interferes, but I also can't see how your proposal deals with this case. Can you provide more details? Just saying a BO has scanout permission isn't sufficient either, since CRTC-output mappings are important too

Re: Clip Lists

2007-11-28 Thread Stephane Marchesin
On 28 Nov 2007 06:19:39 +0100, Soeren Sandmann [EMAIL PROTECTED] wrote: Stephane Marchesin [EMAIL PROTECTED] writes: I fail to see how this works with a lockless design. How do you ensure the X server doesn't change cliprects between the time it has written those in the shared ring

Re: DRI2 and lock-less operation

2007-11-28 Thread Stephane Marchesin
On 11/28/07, Keith Packard [EMAIL PROTECTED] wrote: On Wed, 2007-11-28 at 00:52 +0100, Stephane Marchesin wrote: The third case obviously will never require any kind of state re-emitting. Unless you run out of hardware contexts. Well, in that case we (plan to) bang the state registers

Re: Swapbuffers [was: Re: DRI2 and lock-less operation]

2007-11-28 Thread Stephane Marchesin
On 11/28/07, Keith Whitwell [EMAIL PROTECTED] wrote: In my ideal world, the entity which knows and cares about cliprects should be the one that does the swapbuffers, or at least is in control of the process. That entity is the X server. Instead of tying ourselves into knots trying to

Re: Clip Lists

2007-11-28 Thread Stephane Marchesin
On 11/28/07, Keith Whitwell [EMAIL PROTECTED] wrote: Stephane Marchesin wrote: On 28 Nov 2007 06:19:39 +0100, *Soeren Sandmann* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Stephane Marchesin [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] writes: I fail to see

Re: DRI2 and lock-less operation

2007-11-27 Thread Stephane Marchesin
On 11/27/07, Thomas Hellström [EMAIL PROTECTED] wrote: Kristian Høgsberg wrote: On Nov 22, 2007 4:03 AM, Thomas Hellström [EMAIL PROTECTED] wrote: ... There are probably various ways to do this, which is another argument for keeping super-ioctls device-specific. For i915-type

Re: DRI2 and lock-less operation

2007-11-27 Thread Stephane Marchesin
On 11/27/07, Keith Packard [EMAIL PROTECTED] wrote: On Mon, 2007-11-26 at 17:15 -0500, Kristian Høgsberg wrote: -full state I assume you'll deal with hardware which supports multiple contexts and avoid the need to include full state with each buffer? That's what we do already for

Re: DRI2 and lock-less operation

2007-11-27 Thread Stephane Marchesin
On 11/22/07, Kristian Høgsberg [EMAIL PROTECTED] wrote: Hi all, I've been working on the DRI2 implementation recently and I'm starting to get a little confused, so I figured I'd throw a couple of questions out to the list. First of, I wrote up this summary shortly after XD

Re: DRI2 and lock-less operation

2007-11-27 Thread Stephane Marchesin
On 11/27/07, Kristian Høgsberg [EMAIL PROTECTED] wrote: On Nov 27, 2007 11:48 AM, Stephane Marchesin [EMAIL PROTECTED] wrote: On 11/22/07, Kristian Høgsberg [EMAIL PROTECTED] wrote: ... It's all delightfully simple, but I'm starting to reconsider whether the lockless bullet point

Re: DRI2 and lock-less operation

2007-11-27 Thread Stephane Marchesin
On 11/27/07, Kristian Høgsberg [EMAIL PROTECTED] wrote: Yeah - I'm trying to limit the scope of DRI2 so that we can have redirected direct rendering and GLX1.4 in the tree sooner rather than later (before the end of the year). Maybe the best way to do that is to keep the lock around for now

Re: [2.6 patch] make drm_sg_alloc() static

2007-10-24 Thread Stephane Marchesin
On 10/24/07, Adrian Bunk [EMAIL PROTECTED] wrote: drm_sg_alloc() can now become static. FWIW there is at least one consumer of it in drm git. Stephane - This SF.net email is sponsored by: Splunk Inc. Still grepping

Re: Current state

2007-01-25 Thread Stephane Marchesin
Dave Brown wrote: Hi there, I've recently become interested in the Nouveau project. Specifically I'm considering looking at porting it to a relatively unknown operating system called RISC OS that is based on the ARM processor. The platform I would be targeting currently has uses

Re: [noveau] Nv03-06 driver source code

2007-01-24 Thread Stephane Marchesin
Svante Signell wrote: Dear Noveau developers, Some years ago, around 2000-2002 there was a guy in New Zealand, David, working on Nvidia drivers, see the message at the Utah-GLX mailing list archive from April 2002: http://sourceforge.net/mailarchive/forum.php?thread_id=612267forum_id=3646

Re: mesa: Branch 'master'

2007-01-17 Thread Stephane Marchesin
Keith Whitwell wrote: configs/linux-dri-debug | 16 1 files changed, 16 insertions(+) New commits: diff-tree 3bfbe63806cee1c44da2625daf069b719f2a6097 (from 747c9129c0b592941b14c290ff3d8ab22ad66acb) Author: Keith Whitwell [EMAIL PROTECTED] Date: Wed Jan 17 08:44:13

Re: mesa: Branch 'master'

2007-01-17 Thread Stephane Marchesin
Keith Whitwell wrote: Stephane Marchesin wrote: Keith Whitwell wrote: configs/linux-dri-debug | 16 1 files changed, 16 insertions(+) New commits: diff-tree 3bfbe63806cee1c44da2625daf069b719f2a6097 (from 747c9129c0b592941b14c290ff3d8ab22ad66acb) Author

Re: [nouveau] a million little pieces affecting nvidia drivers

2007-01-15 Thread Stephane Marchesin
Alexy Khrabrov wrote: Philipp, Mark -- Thanks for the concise and extremely useful explanation! This is worthy of being on the front page of a wiki. Also, there is that : http://people.freedesktop.org/~ajax/dri-explanation.txt Stephane

Re: [nouveau] Formal offer from the nouveau driver pledge drive

2007-01-11 Thread Stephane Marchesin
David Nielsen wrote: Dear Nouveau developers It is my pride and honor on behalf of myself and 1247 other pledgers (as of current writing) to formally offer up the sum of ~10.000$ in the form of 1248 pledges of at least 10$ each. It is entirely up to you, the nouveau developers, if you want

Re: [nouveau] drm/nouveau locks on suse 10.2 with nvidia GeForce 2 Go

2007-01-11 Thread Stephane Marchesin
Alexy Khrabrov wrote: [forwarding to the list as well] Here it is, below. I manually modprobe agpgart to make drm.ko happy. Do I have to recompile something else -- it complains about drm? The screen goes blank and doesn't come back, but ctrl-alt-del still reboots. Cheers, Alexy

Re: [nouveau] drm/nouveau locks on suse 10.2 with nvidia GeForce 2 Go

2007-01-10 Thread Stephane Marchesin
Alexy Khrabrov wrote: Greetings -- compiled drm and nouveau yesterday from git and tried to run X -- hangs at the loading stage. Xorg.0.log attached. I've followed the following checks: -- kernel compiled with DRM disabled -- binary nvidia module not loaded The drm installed libdrm.so in

Re: Interest for PCI / PCIe tracing for Nouveau -project?

2007-01-06 Thread Stephane Marchesin
Phillip Ezolt wrote: Stephane, What tools do you use for tracing? I know that you have the renouveau tool and libsegfault. I'm hacking on the ATI stuff, and it would be handy to have code which can just out what MMIO writes the kernel driver is doing. Do you guys have anything to do

Re: Interest for PCI / PCIe tracing for Nouveau -project?

2006-12-27 Thread Stephane Marchesin
Simen Thoresen wrote: Hi Nouveau- (and other cheap PCI and PCIe -graphics users) I have several PCI and PCIe tracers available through my employer, and will be able to purchase low-end versions of modern video-cards (preferably PCI versions, but possibly PCIe versions as well) for

Re: Tried it on my G5 Quad

2006-12-15 Thread Stephane Marchesin
Michael Buesch wrote: On Friday 15 December 2006 16:53, Michel Dänzer wrote: On Fri, 2006-12-15 at 15:17 +0100, Michael Buesch wrote: I just tried to load the nouveau driver on my Apple G5 Quad machine. The kernel module loaded fine, but an attempt to start the x-server resulted in a

Re: Porting DRI to New Platform

2006-11-06 Thread Stephane Marchesin
[EMAIL PROTECTED] wrote: Hello, I'm Dee Sharpe and I have been working on the Syllable port of Mesa3d. Now it is time to move on to hardware acceleration. What would it take to port the DRI to another windowing system? The glue code that I have to write will be in C++. If anyone has

Re: Where to start?

2006-10-22 Thread Stephane Marchesin
Anna Lissa Cruz wrote: Hi all, I just signed onto the list. I'm working with Rudi Cilibrasi and wondering where's the best place to start contributing. We're both C programmers, with some OpenGL experience, and have NV35 and NV36 cards to play with. We have checked out the feature

Re: question on nv35 versus nv30 protocol

2006-10-22 Thread Stephane Marchesin
Rudi Cilibrasi wrote: Hi everybody, I have just started trying to contribute to this project and got as far as identifying chip family for the two cards I have access to here: NV35 and NV36. I added a column for NV35 assuming that the protocol would be different than NV30 in the TODO

Re: DRM memory manager on cards with hardware contexts

2006-09-19 Thread Stephane Marchesin
Thomas Hellström wrote: Benjamin Herrenschmidt wrote: On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote: But this should be the same problem encountered by the agpgart driver? x86 and x86-64 calls change_page_attr() to take care of this. On powerpc it is simply a noop.

DRM memory manager on cards with hardware contexts

2006-09-17 Thread Stephane Marchesin
Hello, Before explaining the issue, let me first introduce the context a bit. We are working on hardware that supports multiple contexts. By allocating one context to each application, we can achieve full graphics command submission from user space (each context is actually simply a command

Re: drm addmap broken on 32bit archs

2006-08-28 Thread Stephane Marchesin
Stephane Marchesin wrote: Hello, The drm addmap code got broken with the recent switch to the hash table implementation. Specifically, when two maps have the same adress on 32 bits, they end up with the same key and nothing is done to resolve the collision, which results in a failind addmap

Re: disconnected texture tiles

2006-08-15 Thread Stephane Marchesin
James C Georgas wrote: Let me try that again, with correct pasting: On Mon, 2006-14-08 at 02:07 +0200, Stephane Marchesin wrote: That's a known bug in those applications. I submitted a fix to ppracer some time ago, which was merged. If you can name other applications, I suppose authors

Re: disconnected texture tiles

2006-08-13 Thread Stephane Marchesin
James C Georgas wrote: There are black grid lines between some terrain tiles in various games I have. It seems to happen in both software and direct rendering. I'm using this morning's cvs HEAD for mesa and dri. System is dual Opteron. Video card is FireGL X1-128 OS is Gentoo amd64.

Re: [nouveau] glViewport()

2006-04-30 Thread Stephane Marchesin
Dawid Gajownik wrote: Hi! Hi, I have finished documenting glViewport() and glScissor() functions → http://fedora.pl/~gajownik/nouveau/glViewport_and_Scissor_NV17 Very nice ! Output of glViewport depends on 13 variables (I still haven't figured out three of them) so it took me some

Re: [nouveau] glViewport()

2006-04-30 Thread Stephane Marchesin
Dawid Gajownik wrote: Dnia 04/30/2006 02:47 PM, Użytkownik Stephane Marchesin napisał: What do you think about renaming NV10_SET_VIEWPORT_DIMS to NV10_SCISSOR? If you execute glEnable(GL_SCISSOR_TEST) function, NV10_SET_VIEWPORT_DIMS changes dimensions of scissor box (not viewport ones

Re: nouveau: how does it relate to the free beos driver?

2006-04-26 Thread Stephane Marchesin
Paul Wise wrote: Hi all, [I'm not subscribed, please CC me] I'm wondering how nouveau relates to this free nvidia 3D driver for beos. Perhaps you could use code from it? I think it is utah-glx related. http://be-hold.blogspot.com/ Hi, Yes, we know about that 3D driver. I'm in contact

Re: nouveau: how does it relate to the free beos driver?

2006-04-26 Thread Stephane Marchesin
Michael Schreckenbauer wrote: Hello, Am Mittwoch, 26. April 2006 17:02 schrieb Stephane Marchesin: Paul Wise wrote: Hi all, I'm wondering how nouveau relates to this free nvidia 3D driver for beos. Perhaps you could use code from it? I think it is utah-glx related. http

Re: [nouveau] input range

2006-04-23 Thread Stephane Marchesin
Dawid Gajownik wrote: Hi! Hi, I was told on fedora-devel-list about nouveau project and I would like to help somehow ;) Although I don't have good programming skills, renouveau tool is quite easy to use so I could try to guess how some OpenGL commands work (examples in doc directory are

Texture replacement policy and occlusion queries

2006-01-16 Thread Stephane Marchesin
Hi, I was considering how complicated it can be to implement a texture replacement policy, and then I had the following idea : we could make use of hardware cocclusion queries on cards that support them to determine actual texture usage and thus have a good texture replacement policy. Here

Re: r300 + NWN

2005-12-11 Thread Stephane Marchesin
Philipp Klaus Krause wrote: Adam K Kirchhoff schrieb: I'm sure this confirms what are already known issues with the r300 driver, but felt it'd be worth posting anyway. There's definitely something bizarre going on with textures. They're much crisper with the fglrx driver. To me

Re: [Mesa3d-dev] DRM/Mesa Patches

2005-12-08 Thread Stephane Marchesin
khaqq wrote: On Tue, 06 Dec 2005 13:13:35 +0100 Roland Scheidegger [EMAIL PROTECTED] wrote: vehemens wrote: 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

Re: r128 software features patch

2005-10-08 Thread Stephane Marchesin
Philipp Klaus Krause wrote: I hvae removed GL_EXT_cull_vertex from my patch, since Brian wants to remove it from Mesa, too. Since the r128 doesn't have hardware tcl all interesting features of Mesa's software tcl should be exposed. This patch adds support for GL_ARB_vertex_buffer_object,

Re: r128 software features patch

2005-10-08 Thread Stephane Marchesin
Philipp Klaus Krause wrote: Stephane Marchesin schrieb: What is the point of advertising GL_MESA_pack_invert if it's not implemented ? Stephane According to extensions specification this extension's main purpose seems to be making application developers life a little bit easier, just

Re: Kernel / user interface for new memory manager

2005-08-24 Thread Stephane Marchesin
Michel Dänzer wrote: Security is more than just the memory manager. To enforce video memory protection, we'd have to audit the code and add memory protection to existing drm modules. That is quite a lot of work, and requires extensive knowledge of each card. So I don't think it's worth the

Re: Kernel / user interface for new memory manager

2005-08-23 Thread Stephane Marchesin
Stephane Marchesin wrote: Now, there is one question that sounds to me like it will have implications over the whole memory manager design : do we want to enforce video memory ownership ? Ok, here is what came out of the irc meeting : - we don't need to enforce video memory ownership

Re: Kernel / user interface for new memory manager

2005-08-23 Thread Stephane Marchesin
Michel Dänzer wrote: You'd need the same stuff that you need to protect system memory. You'd need a hardware MMU that could block the accesses. It might be possible to do it in software by looking at the command stream, but I suspect that would be pretty expensive. It would be worth a try, I

Re: Kernel / user interface for new memory manager

2005-08-23 Thread Stephane Marchesin
Alan Cox wrote: The log design presents numerous opportunities for rogue processes to do bad things. At some level, that's inherent in the nature of direct rendering. If you don't trust the processes, don't enable direct rendering. Thats a very poor answer to the problem. DRI needs to be

  1   2   >