On Fri, May 31, 2002 at 11:44:15PM +0100, Keith Whitwell wrote:
> I'm off on a mountain-bikin' safari... I won't be checking email, back on
> the 10th of June.
Have a good holiday.
--
Michael.
___
Don't miss the 2002 Sprint PCS App
On Fri, May 31, 2002 at 11:56:05PM +0200, Simon Cahuk wrote:
> Hi, I have Rh 7.3.
> I can't use DRI with higher resolution then 1024x768. Why? I'm the pakcages
> that come with RH 7.3.
Which video card?
--
Michael.
___
Don't miss th
I'm off on a mountain-bikin' safari... I won't be checking email, back on the
10th of June.
Keith
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/ind
Simon Cahuk wrote:
> Hi, I have Rh 7.3.
> I can't use DRI with higher resolution then 1024x768. Why? I'm the pakcages
> that come with RH 7.3.
Perhaps you run out of video memory above that resolution. DRI requires back
buffer, z buffer and texture ram on the card -- it adds up.
Keith
_
Michel Dänzer wrote:
> On Fri, 2002-05-31 at 14:09, Keith Whitwell wrote:
>
>>>I seem to have discovered a nasty interaction between framebuffer and DRI/DRM
>>>in OpenGL applications. I can reproduce this problem in at least Return to
>>>Castle Wolfenstein (version 1.1b) and Tux Racer.
>>>
>>>
Hi, I have Rh 7.3.
I can't use DRI with higher resolution then 1024x768. Why? I'm the pakcages
that come with RH 7.3.
Thanks,
Simon
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- h
On Fri, 2002-05-31 at 14:09, Keith Whitwell wrote:
> >
> > I seem to have discovered a nasty interaction between framebuffer and DRI/DRM
> > in OpenGL applications. I can reproduce this problem in at least Return to
> > Castle Wolfenstein (version 1.1b) and Tux Racer.
> >
> > I am using a 32
On Fri, 2002-05-31 at 02:30, Felix Kühling wrote:
>
> I reported lockups shortly after starting the Xserver with a gcc 3.0
> compiled drm module that triggered the strange permission problem. Now I
> tested it without loading the dri Xserver module in XF86Config and got
> the same lockup. The fo
Keith Whitwell wrote:
> Linus Torvalds wrote:
>
>>
>> On Fri, 31 May 2002, Tim Smith wrote:
>>
>>> I seem to be observing the behaviour that if, on entry to
>>> do_cp_idle() the
>>> FIFO is not empty already, it never will be empty and the whole thing
>>> goes
>>> pear shaped. Thus, if a big co
> Different compilers may indeed have different layout rules, but I haven't
> heard of any such changes in gcc-3.x, and it would be fairly unexpected.
> Now, if the kernel was compiled with C++ and used virtual inheritance,
> that would be a different issue ;)
Also, I've heard they've changed s
Linus Torvalds wrote:
>
> On Fri, 31 May 2002, Tim Smith wrote:
>
>>I seem to be observing the behaviour that if, on entry to do_cp_idle() the
>>FIFO is not empty already, it never will be empty and the whole thing goes
>>pear shaped. Thus, if a big collection of commands is just followed by mor
On 31 May 2002, Michel Dänzer wrote:
>
> Kernel modules may rely on kernel internal data structures, which may be
> laid out differently in memory by different compilers. I don't think you
> can expect this to work, but if I'm wrong I'm sure Linus will LART me.
> :)
Different compilers may indee
On Fri, 2002-05-31 at 14:35, Sergey V. Udaltsov wrote:
> > Great Felix! I bet that you slept much better after too! ;-)
> But the question is still open - what in DRM interfaces makes them so
> gcc-dependable? Why gcc3-built module cannot properly interact with
> gcc2.96-built kernel?
Kernel modu
On Fri, 31 May 2002, Tim Smith wrote:
>
> I seem to be observing the behaviour that if, on entry to do_cp_idle() the
> FIFO is not empty already, it never will be empty and the whole thing goes
> pear shaped. Thus, if a big collection of commands is just followed by more
> commands this doesn't
On Friday 31 May 2002 4:12 pm, Keith Whitwell scribed numinously:"
> Tim Smith wrote:
> > On Friday 31 May 2002 2:00 pm, Keith Whitwell scribed numinously:"
> >
> >>Tim Smith wrote:
> >>>I conclude from this that writing the ring tail register causes the
> >>>card to fetch all the commands up unti
Tim Smith wrote:
> On Friday 31 May 2002 2:00 pm, Keith Whitwell scribed numinously:"
>
>>Tim Smith wrote:
>>
>>>I conclude from this that writing the ring tail register causes the
>>>card to fetch all the commands up until that point and feed them to its
>>>FIFO, which may fill it... It's certai
On 2002.05.31 13:35 Sergey V. Udaltsov wrote:
> > Great Felix! I bet that you slept much better after too! ;-)
> But the question is still open - what in DRM interfaces makes them so
> gcc-dependable? Why gcc3-built module cannot properly interact with
> gcc2.96-built kernel? Or this question is n
Karl Rasche wrote:
>>The most appropriate way to do this is with a single copy from the user's data
>>to a dma buffer and then fire off the blit from agp->screen.
>>
>
> Keith,
>
> Thanks for answering all my questions, i think i have this working in a
> somewhat proper mannor..
>
>
>>When th
On Friday 31 May 2002 2:00 pm, Keith Whitwell scribed numinously:"
> Tim Smith wrote:
> > I conclude from this that writing the ring tail register causes the
> > card to fetch all the commands up until that point and feed them to its
> > FIFO, which may fill it... It's certainly possible for the F
> The most appropriate way to do this is with a single copy from the user's data
> to a dma buffer and then fire off the blit from agp->screen.
Keith,
Thanks for answering all my questions, i think i have this working in a
somewhat proper mannor..
> When that's working, you can consider fancy
Tim Smith wrote:
> On Thursday 30 May 2002 9:15 am, Keith Whitwell scribed numinously:"
>
>>>I've attempted some rather pathetic rate-adaption to make everything
>>>slow down when the FIFO gets full. It utterly murders performance but
>>>it did prevent the lockup from occurring. I modified ADVANC
Michael wrote:
> On Fri, May 31, 2002 at 01:12:09PM +0100, Keith Whitwell wrote:
>
>>It seems like there are additional problems with tuxkart, beyond the
>>lineloop issue. I'm still getting hangs...
>>
>
> Damn, I was pretty convinced it wasn't hanging albeit with temp broken line
> loops, I
> Great Felix! I bet that you slept much better after too! ;-)
But the question is still open - what in DRM interfaces makes them so
gcc-dependable? Why gcc3-built module cannot properly interact with
gcc2.96-built kernel? Or this question is not interesting to anyone?
Sergey
__
On Fri, May 31, 2002 at 01:12:09PM +0100, Keith Whitwell wrote:
> It seems like there are additional problems with tuxkart, beyond the
> lineloop issue. I'm still getting hangs...
Damn, I was pretty convinced it wasn't hanging albeit with temp broken line
loops, I didn't trigger a crash yester
It seems like there are additional problems with tuxkart, beyond the lineloop
issue. I'm still getting hangs... I did win my first race, however...
Keith
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August
On Fri, 31 May 2002, Chris Howells wrote:
> I seem to have discovered a nasty interaction between framebuffer and DRI/DRM
> in OpenGL applications. I can reproduce this problem in at least Return to
> Castle Wolfenstein (version 1.1b) and Tux Racer.
>
> I am using a 32 MB ATI Rage Pro 128 on De
Chris Howells wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> I seem to have discovered a nasty interaction between framebuffer and DRI/DRM
> in OpenGL applications. I can reproduce this problem in at least Return to
> Castle Wolfenstein (version 1.1b) and Tux Racer.
>
>
Hi,
On Friday 31 May 2002 12:54 pm, Chris Howells wrote:
> I seem to have discovered a nasty interaction between framebuffer and
> DRI/DRM in OpenGL applications. I can reproduce this problem in at least
> Return to Castle Wolfenstein (version 1.1b) and Tux Racer.
Meant to say this before...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I seem to have discovered a nasty interaction between framebuffer and DRI/DRM
in OpenGL applications. I can reproduce this problem in at least Return to
Castle Wolfenstein (version 1.1b) and Tux Racer.
I am using a 32 MB ATI Rage Pro 128 on De
On 2002.05.31 02:03 Felix Kühling wrote:
> On Fri, 31 May 2002 02:30:11 +0200
> Felix Kühling <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I reported lockups shortly after starting the Xserver with a gcc 3.0
> > compiled drm module that triggered the strange permission problem. Now
> I
> > tested
>
> Obviously :-) Otherwise the trace in my last mail would have indicated a
> crash, but it recovered from that.
>
> It does seem like a good idea to know how much we just gave the card to do
> though, so we have some idea to how long to wait next time we do wait.
>
> It may be significant
On 2002.05.31 02:53 Leif Delgass wrote:
> On Thu, 30 May 2002, José Fonseca wrote:
>
> > Leif,
> >
> > On 2002.05.30 02:02 José Fonseca wrote:
> > > ... Tomorrow I'll take a look more carefully to see if I find
> anything
> > > suspicious. ...
> >
> > I've been analyzing the diff very carefully a
On Thursday 30 May 2002 10:24 am, Keith Whitwell scribed numinously:"
> > I conclude from this that writing the ring tail register causes the
> > card to fetch all the commands up until that point and feed them to its
> > FIFO, which may fill it... It's certainly possible for the FIFO to go
> > fr
33 matches
Mail list logo
