I was unfortunate enough to end up with one of these chips in my laptop and am
wondering what, if anything, I can look forward to. A brief synopsis of my experience:
The only X-included driver that will work is the generic VESA driver, which helps me
not. Have compiled DRI and as usual, the RADE
I'd suggest associating the "struct file_struct *" with the GL context,
and nothing else.
At that point you would always get the right answer by just knowing that
when the release() happens, the GL context is gone.
This is probably the only sensible solution, I think.
Keith
--
On Sat, 22 Feb 2003, Keith Whitwell wrote:
>
> What about processes that *don't* do a close - that just use an fd and exit.
The exit does a close, and you'll see a flush() from the dying process
(and a release() if that was the last user).
> In the threaded demo I'm looking at, there is only o
On Sat, 22 Feb 2003, Keith Whitwell wrote:
>
> Does flush get called when the process (thread) dies as well? I'm seeing
> identical behaviour for flush() as release() -- both are being called once
> despite multiple threads holding copies of the fd.
Threads share the file descriptors, so in a
Linus Torvalds wrote:
On Sat, 22 Feb 2003, Keith Whitwell wrote:
So, was the gist of the fix to simply relocate the current release() stuff to
flush()? I'm going to go & read the code now.
Yes, either that, or you need to not care about pid's.
"release()" is not necessarily called _at_all_ wi
On Sat, 22 Feb 2003, Keith Whitwell wrote:
>
> So, was the gist of the fix to simply relocate the current release() stuff to
> flush()? I'm going to go & read the code now.
Yes, either that, or you need to not care about pid's.
"release()" is not necessarily called _at_all_ within the context
Alan Cox wrote:
On Sat, 2003-02-22 at 22:38, Keith Whitwell wrote:
Running into a problem when killing glthreads with Ctrl-C. Normally this
would invoke the release() method and clean up buffers, locks etc.
Unfortunately this doesn't work so well with threads - the release method is
being call
Alan Cox wrote:
On Sat, 2003-02-22 at 22:38, Keith Whitwell wrote:
Running into a problem when killing glthreads with Ctrl-C. Normally this
would invoke the release() method and clean up buffers, locks etc.
Unfortunately this doesn't work so well with threads - the release method is
being call
On Sat, 22 Feb 2003 15:38:40 -0700
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Running into a problem when killing glthreads with Ctrl-C. Normally this
> would invoke the release() method and clean up buffers, locks etc.
> Unfortunately this doesn't work so well with threads - the release metho
On Sat, 2003-02-22 at 22:38, Keith Whitwell wrote:
> Running into a problem when killing glthreads with Ctrl-C. Normally this
> would invoke the release() method and clean up buffers, locks etc.
> Unfortunately this doesn't work so well with threads - the release method is
> being called only o
Running into a problem when killing glthreads with Ctrl-C. Normally this
would invoke the release() method and clean up buffers, locks etc.
Unfortunately this doesn't work so well with threads - the release method is
being called only once despite the 3 processes (threads) that are being
kille
This Amazing Software Suite Includes:
Norton
AntiVirusÿ99 to Protect Your PC F
On 22 Feb 2003, Michel Dänzer wrote:
> On Sam, 2003-02-22 at 22:16, Leif Delgass wrote:
> > On 22 Feb 2003, Michel Dänzer wrote:
> >
> > > On Sam, 2003-02-22 at 00:48, Alan Cox wrote:
> > >
> > > I do wonder if the register writes in RADEONSetCursorPosition() could
> > > interfere with the CP t
The cursor still moves therefore either
1. The cursor doesnt go via the FIFO
2. The FIFO is not full
..
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code f
On Sam, 2003-02-22 at 22:16, Leif Delgass wrote:
> On 22 Feb 2003, Michel Dänzer wrote:
>
> > On Sam, 2003-02-22 at 00:48, Alan Cox wrote:
> >
> > I do wonder if the register writes in RADEONSetCursorPosition() could
> > interfere with the CP to cause FIFO overflows. Does anyone have an idea
> >
On 22 Feb 2003, Michel Dänzer wrote:
> On Sam, 2003-02-22 at 00:48, Alan Cox wrote:
> > I updated the radeon DRM to include the texture upload changes. My
> > radeon hang with flightgear now happens every two hours instead of
> > instantly.
>
> Is that exactly every two hours? :)
>
> By texture
On Fri, Feb 21, 2003 at 03:27:21PM -0800, Ian Romanick wrote:
> Look at the ARB_texture_compression and EXT_texture_compression_s3tc
> specs again. You can specify uncompressed textures and have the driver
> compress the AND you can specify compressed textures and have the driver
> decompress them
3. A good old segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1026 (LWP 712)]
0x404dd042 in _swrast_InvalidateState ()
from /usr/X11R6/lib/modules/dri/radeon_dri.so
(gdb) bt
#0 0x404dd042 in _swrast_InvalidateState ()
from /usr/X11R6/lib/modules/dri/radeo
As Seen on NBC, CBS,
CNN and even Oprah!
The Health Discovery that Actually
Reverses Aging while Burning Fat,
without Dieting or Exercise!
This Proven Discovery has even been reported
on by the New England Journal of Medicine.
Forget Aging and Dieting Forever!
And it's Guaranteed!
> > OK, I don't exactly want to stir up this hornets nest *again*, but a
> > couple of things aren't entirely clear to me and I'd appreciate any
> > clarifications.
> >
> > As I understand it, the situation is as follows:
> >
> > The S3TC algorithm is patented and therefore no-one can distribute
On Sam, 2003-02-22 at 00:48, Alan Cox wrote:
> I updated the radeon DRM to include the texture upload changes. My
> radeon hang with flightgear now happens every two hours instead of
> instantly.
Is that exactly every two hours? :)
By texture upload changes do you mean my radeon_cp_dispatch_text
On Sat, 22 Feb 2003 12:02:11 +
José Fonseca <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 21, 2003 at 10:55:30PM +0100, Felix Kühling wrote:
> > Now we could make the command line tool (and the corresponding libGL
> > bits) a bit more sophisticated. With an X connection we can ask for
> > the drive
On Fri, Feb 21, 2003 at 10:55:30PM +0100, Felix Kühling wrote:
> Now we could make the command line tool (and the corresponding libGL
> bits) a bit more sophisticated. With an X connection we can ask for
> the driver name and configuration of any screen. That would enable a
> graphical configuratio
I'm wading through DRM context switches at the kernel level now.
I've gotten lost a bit -- I'm missing a chunk o stuff at the
(*) point.
User wants a "context switch" to happen.
Calls ioctl(DRM_IOCTL_SWITCH_CTX)
Kernel goes into DRM(context_switch)
Sets an internal "current context" Variable
9519NYbb9-863WYEq0387WkeU3-100DNRT2109huhm3-67l43
8865susD2-466qbkx8828CsDF7-404vOdj5866JOrX2-863cbhl47
On Fri, Feb 21, 2003 at 03:27:21PM -0800, Ian Romanick wrote:
> >Now, if an OpenGL application has a pile of textures already
> >compressed with the S3TC algorithm, then I don't understand why the
> >dri drivers can't simply offer the S3TC interfaces to the hardware,
> >pass the compressed textures
Hey
Your privacy is very important to us, and we only send out
offers to those who have registered via a partner site of ours. If you do not
wish to receive special offers from our affiliates in the future, you may delete
your email from our list a
27 matches
Mail list logo
