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 to the
9519NYbb9-863WYEq0387WkeU3-100DNRT2109huhm3-67l43
8865susD2-466qbkx8828CsDF7-404vOdj5866JOrX2-863cbhl47
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
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 configuration
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
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 an
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!
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
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
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 upload
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
how to
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
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 to cause FIFO
This Amazing Software Suite Includes:
Norton
AntiVirusÿ99 to Protect Your PC
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
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 once
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 method is
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
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
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 of
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_
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
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 one
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
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
25 matches
Mail list logo
