On Sat, Feb 21, 2004 at 06:14:02PM +0100, Felix Kühling wrote:
> Sounds like a good idea to remove outdated information or at least make
> it inaccessible.
> But instead of redirecting to the new Download page I'd
> redirect to the Wiki front page to make people aware that the old
> website is dea
> oprofile perhaps might help.
The problem is oprofile is it works only on sample count which does not
reflect how many times a function was called, nor does it reflect time per
function call. It only shows that then oprofile checked, it was in that
function.
Here is the initial oprofile done on
On Sat, 21 Feb 2004 15:22:26 +0100
Unai Garro <[EMAIL PROTECTED]> wrote:
> On Thursday 19 February 2004 22:25, Felix Kühling wrote:
>
> > Now I consider the driver pretty stable
> > as far as lockups are concerned, a good point for starting to turn it
> > inside out, break things and make life m
--- Felix Kühling <[EMAIL PROTECTED]> wrote:
> Hi,
>
> DPMS never worked on my notebook with ProSavageDDR. The problem is
> that
> the register that controls HSync and VSync signals of the CRT doesn't
> have any effect on the LCD display. The attached patch disables the
> LCD
> display via the bi
Felix Kühling wrote:
and many more which I suspect are just because the compiler got
confused. The problem seems to be that list_for_each_entry_safe is not
defined. Erdi, did you forget to include it in the patch or is my
working tree missing something?
Felix
Which kernel version are you usin
On Sat, 21 Feb 2004 20:44:37 +0100
Felix Kühling <[EMAIL PROTECTED]> wrote:
> On Fri, 20 Feb 2004 22:56:20 +
> Keith Whitwell <[EMAIL PROTECTED]> wrote:
>
[snip]
> >
> > I've committed this, but I'm just about to leave on holidays. If there are
> > any problems hopefully Erdi will be able
On Fri, 20 Feb 2004 22:56:20 +
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Erdi Chen wrote:
> > This is a patch to call the context handles destructors and free the
> > context bitmap entries when a process does not destroy its contexts
> > before it exits. It saves context handles in a link
On Sat, 21 Feb 2004 16:41:56 +
José Fonseca <[EMAIL PROTECTED]> wrote:
> The errors were caused by an attemp to list files in
> /home/groups/d/dr/dri/htdocs/snapshots which no longer exists after the
> snapshots been move to d.f.o. I fixed
> it just so that it shows the full page without error
The errors were caused by an attemp to list files in
/home/groups/d/dr/dri/htdocs/snapshots which no longer exists after the
snapshots been move to d.f.o. I fixed
it just so that it shows the full page without errors.
Still, I wonder if there any point having this page (and probably other
alike) a
On Sat, 21 Feb 2004 02:36:26 +
Sérgio Monteiro Basto <[EMAIL PROTECTED]> wrote:
> On Thu, 2004-02-19 at 15:46, Felix Kühling wrote:
> > I don't see a reason to mess with Mesa on the savage-2-0-0-branch now.
>
> ok,
> This is not my code, this is Brian Paul code.
> So please apply, I remember
On Fri, 20 Feb 2004 17:29:07 -0800
Tim Roberts <[EMAIL PROTECTED]> wrote:
> Alex Deucher wrote:
>
> >Felix can probably phrase this better than I since he has worked more
> >closely with the 3D code. however, I think what he is asking is how
> >should vertex commends be formatted when sent to th
On Sat, 2004-02-21 at 09:54, Chris Ison wrote:
> ok, let me get this in perspective
>
> R9200R8500
> DRI14.62103716.860273
> fglrx39.46159444.228085
>
> I have been trying to hunt down the slowdown in DRI, I even if (0)'s all
> occurances of sched_yield () whic
On Sat, 21 Feb 2004, Chris Ison wrote:
>ok, let me get this in perspective
>
>R9200R8500
>DRI14.62103716.860273
>fglrx39.46159444.228085
>
>I have been trying to hunt down the slowdown in DRI, I even if (0)'s all
>occurances of sched_yield () which is slower in
On Fri, 20 Feb 2004, Alex Deucher wrote:
>> the main reason mach64 is still on a branch in DRI is it is insecure
>> by
>> default, I'm going to look into it when I've moved apartments and got
>> myself settled in again :-), I don't think putting insecure code into
>> the
>> trunk where it may get
14 matches
Mail list logo
