On Thu, Apr 8, 2010 at 16:37, Jesse Barnes wrote:
> On Thu, 8 Apr 2010 18:38:03 -0400
> Alex Deucher wrote:
>
>> On Thu, Apr 8, 2010 at 6:21 PM, Brian Paul wrote:
>> >
>> > Unless there's some objection I'm going to subscribe everyone to the
>> > new FD.O-based mesa-dev mailing list who's on the
On Thu, Mar 4, 2010 at 23:44, Ingo Molnar wrote:
>
> * Pekka Enberg wrote:
>
>> On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar wrote:
>> > The conclusion is crystal clear, breaking an ABI via a "flag day"
>> > cleanup/feature/etc is:
>> >
>> > ?- wrong
>> >
>> > ?- harmful
>> >
>> > ?- limits the d
On Thu, Mar 4, 2010 at 15:03, Linus Torvalds
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
>> > > before it
On Thu, Mar 4, 2010 at 15:09, Brian Paul 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
>> leaves as
On Thu, Mar 4, 2010 at 12:07, Linus Torvalds
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 provide
>> compat
On Sat, Feb 6, 2010 at 11:47, Émeric Maschino wrote:
> 2010/2/4 Jerome Glisse :
>> 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 command looks like (packet pm4 stuff). Note tha
On Tue, Feb 2, 2010 at 13:19, Émeric Maschino wrote:
> 2010/2/1 Stephane Marchesin :
>> 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 a bunch of years ago. F
On Mon, Feb 1, 2010 at 13:17, Émeric Maschino wrote:
> 2010/1/31 Jerome Glisse :
>>>
>>> Eventually, strace log is flooded with
>>> ioctl(4, 0xc0106451, 0x6fd530f8) = 0
>>> roughly at the time the CPU charge increases. This is consistent with
>>> what is recorded in syslog:
>>> Jan 29 21:
d, and is in no way supported by nVidia.
>
> Support for nearly the complete range of nvidia hw from nv04->g80 (nv50)
> is available, and the kms driver should support driving nearly all
> output types (displayport is under development still) along with supporting
> su
2009/12/12 Dave Airlie :
> 2009/12/12 Stephane Marchesin :
> 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 contribut
On Sat, Dec 12, 2009 at 00:27, Stephane Marchesin
wrote:
> 2009/12/12 Dave Airlie :
>> 2009/12/12 Stephane Marchesin :
>> 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 w
On Fri, Dec 11, 2009 at 00:58, Alan Cox 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 kernel because the
2009/12/10 Alan Cox :
>> 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 from the nvidia
>> p
On Thu, Dec 10, 2009 at 19:42, Linus Torvalds
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 some questions over th
[oops, with reply-all this time]
On Tue, Nov 17, 2009 at 18:07, Jesse Barnes wrote:
> On Mon, 9 Nov 2009 17:46:44 +0100
> Stephane Marchesin wrote:
>> > And how do I get releases of libdrm out outside of kernel releases?
>> > We're doing libdrms at least twice a ke
2009/11/17 Kristian Høgsberg :
> 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 driver bits from the drm.git
>> repo.
>
>
On Mon, Nov 9, 2009 at 17:42, Eric Anholt wrote:
> On Sun, 2009-11-08 at 23:40 +0100, Stephane Marchesin wrote:
>> On Sun, Nov 8, 2009 at 23:33, Eric Anholt wrote:
>> > On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote:
>> >> On Sun, Nov 8, 2009 at 20:02,
On Mon, Nov 9, 2009 at 11:51, Rémi Cardona 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.
>
> Absolutely. In fa
On Sun, Nov 8, 2009 at 23:33, Eric Anholt wrote:
> On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote:
>> On Sun, Nov 8, 2009 at 20:02, Eric Anholt wrote:
>> > On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote:
>> >> On Sun, Nov 8, 2009 at 19:18,
On Sun, Nov 8, 2009 at 20:02, Eric Anholt wrote:
> On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote:
>> On Sun, Nov 8, 2009 at 19:18, Eric Anholt wrote:
>> > On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote:
>> >> 2009/11/6
On Sun, Nov 8, 2009 at 19:18, Eric Anholt wrote:
> On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin 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.
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 driver bits from the drm.git
> repo. I've put up a repo under
Actually, I don
2009/9/1 Keith Whitwell :
> On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote:
>> Stephane Marchesin wrote:
>> > 2009/8/31 Thomas Hellström :
>> >
>> >
>> >>> The problem I see with Xv-API-in-kernel is that of the various hw
>&g
2009/8/31 Thomas Hellström :
>> 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.
>>
>
> II
2009/8/31 Thomas Hellström :
> 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
>> count on t
2009/7/20 Thomas Hellström :
>
> 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 reverse
> 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
On Fri, Jul 17, 2009 at 15:23, Keith Whitwell 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 guide to
> some
On Fri, Jul 17, 2009 at 13:37, Harald Welte wrote:
> On Fri, Jul 17, 2009 at 07:09:06PM +1000, Dave Airlie wrote:
>> On Fri, Jul 17, 2009 at 4:36 PM, wrote:
>> > To whom it may ceoncern:
>> >The following 3 patches are the DRM kernel module that support VIA
>> > Chorme9 GFX chipset. They are
On Thu, Jun 25, 2009 at 09:46, Jerome Glisse 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 map will reply
On Mon, May 18, 2009 at 03:11, Benjamin Herrenschmidt
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 way SAREA_MAX is def
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 Confere
On Thu, Feb 19, 2009 at 15:46, Alex Deucher wrote:
> On Thu, Feb 19, 2009 at 7:26 AM, Roland Scheidegger
> 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 in rv250
and other r200 family mem
On Wed, Feb 4, 2009 at 11:14, Thomas Hellström wrote:
> Stephane Marchesin wrote:
>> On Thu, Jan 29, 2009 at 09:40, Thomas Hellström wrote:
>>
>>> Owain Ainsworth wrote:
>>>
>>>> On Thu, Jan 29, 2009 at 12:04:22AM +0100, Stephane Marchesin wrote:
>
On Thu, Jan 29, 2009 at 09:40, Thomas Hellström 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 d
On Thu, Jan 29, 2009 at 02:29, 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.
>
&g
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.
http://p.sf.net/sfu/sf-s
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
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
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 lar
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 al
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 an
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 u
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 cli
>
> 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
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 al
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, a
>
> Jerome, Dave, Keith
>
> It's hard to argue against people trying things out and finding it's not
> really what they want, so I'm not going to do that.
>
> The biggest argument (apart from the fencing) seems to be that people
> thinks TTM stops them from doing what they want with the hardwar
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 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
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
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
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 spo
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
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 an
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 e
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
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
> >
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
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 Marches
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
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.
W
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 clipr
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
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&#x
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
>
> ht
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 alread
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.
>
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 thr
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
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=612267&forum_id=3
Keith Whitwell wrote:
> Stephane Marchesin wrote:
>
>> Keith Whitwell wrote:
>>
>>> configs/linux-dri-debug | 16
>>> 1 files changed, 16 insertions(+)
>>>
>>> New commits:
>&g
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
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
---
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
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
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 libdr
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
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
> ma
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 resu
[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 anyon
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
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 m
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 n
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 fi
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 re
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. This is annoying.
Stephane
-
James C Georgas wrote:
> On Tue, 2006-15-08 at 16:56 +0200, Stephane Marchesin wrote:
>
>> No. Maybe that could be made into a driconf option, though, as this
>> question is raised quite often.
>>
>>
> Yeah, that'd be nice.
>
> So, this .drirc
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 c
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 amd6
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
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 time
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
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 wit
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
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 is
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 it
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
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 ea
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,
GL_ARB
1 - 100 of 174 matches
Mail list logo
