On Fri, 24 May 2002, Tim Smith wrote:
Covering about 30 seconds prior to me hitting reset, so the card certainly
seems to be getting rather stuck, because 'done=N' doesn't increment over
that 30 seconds.
Hmm.. I don't know if it is related, but you can get both a Radeon-7500
and a
On Fri, 24 May 2002, Linus Torvalds wrote:
It might even happen with a regular XF-4.2 server (ie switching from using
XF4.2 to DRI CVS tree without rebooting in between), I'll test.
Nope, doesn't happen with regular XF-4.2. But I re-verified that if I run
the gatos drivers first
On Fri, 24 May 2002, José Fonseca wrote:
When doing this you're using the GATOS DRM with the Radeon Mesa X
drivers of DRI CVS. Since the regular X works, it seems that GATOS broke
binary compatibility. Does this happens too when switching GATOS with
XF-4.2?
Note that once I switch away
On Fri, 24 May 2002, Keith Packard wrote:
I submit that we need some sort of plan on how to get this mess resolved;
I'd like to get to a state where 3D and video runs on most chips, and at
least doesn't hang on the others. What I'd like to see is:
+ The kernel driver for the tcl-0-0
On Fri, 24 May 2002, José Fonseca wrote:
I don't know how long you're monitoring, but we discussed this issue of
integration with the kernel tree a week ago. In case you've missed it,
here are the relevant links:
I missed it - I only subscribed yesterday, and while I did take a look at
the
On Fri, 24 May 2002, José Fonseca wrote:
Keith P., even very recentely it was discussed on the Xpert mailing list
that the XFree86 project didn't have the manpower to handle all the
patches that are being submited regularly.
From personal experience, it doesn't get better, it only gets
On Sat, 25 May 2002, Keith Whitwell wrote:
Linus, as this constitues a defacto release of code it's probably good to know
about it when this happens...
It's not a problem, but it does mark a point at which the new interfaces
become public, and it's happened in a different order than the
On Sat, 25 May 2002, Frank C. Earl wrote:
Linus, if you're still listening in, can you spare us a moment to tell us
what consequences quickly mapping and unmapping memory reigons into userspace
has on the system?
It's reasonably fine on UP, and it often _really_ sucks on SMP.
On UP, the
On Sun, 26 May 2002, José Fonseca wrote:
The vertex data alone (no textures here) can be several MBs per frame
Yes, yes, I realize that the cumulative sizes are big. The question is not
the absolute size, but the size of one bunch.
Throwing some numbers just to get a rough idea:
On Mon, 27 May 2002, Jens Owen wrote:
This is an education for me, too. Thanks for the info. Any idea how
heavy IOCTL's are on a P4?
Much heavier. For some yet unexplained reason, a P4 takes about 1us to do
a simple system call. That's on a 1.8GHz system, so it basically implies
that a P4
On Mon, 27 May 2002, Keith Whitwell wrote:
Linus Torvalds wrote:
Much heavier. For some yet unexplained reason, a P4 takes about 1us to do
a simple system call. That's on a 1.8GHz system, so it basically implies
that a P4 takes 1800 cycles to do a int 0x80 + iret, which is just
On 28 May 2002, Al Tobey wrote:
If I run ut on my laptop, the intro and any games run 2-5times faster
than they should.
Does your clock run fast too? Try making a program that just does
gettimeofday().
Sometimes you get strange behaviour on some laptops due to the
undocumented Intel
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 seem
On Fri, 31 May 2002, Keith Whitwell wrote:
Also note that it actually asks for the pixcache to be flushed *twice* - once
by RADEON_PURGE_CACHE (which writes the RADEON_RB2D_DSTCACHE_CTLSTAT via the
ring) and once in radeon_do_pixcache_flush() which writes the register via MMIO.
Btw, why
AMD just sent out this email about a kernel bug/interaction with the AMD
Athlons and AGP GART usage. I'll just quote the whole thing here, it would
be interesting to hear whether the suggested patches seem to make any
difference to any AMD/Radeon problems..
If you have an AMD system and have
On Thu, 13 Jun 2002, José Fonseca wrote:
A system such as bugzilla can address everyone's needs (including Keith's
and Jens').
The way to address the needs of Keith and Jens is probably to let them
ignore the bug tracking, and have others (maybe the originator, maybe just
somebody else)
On Fri, 14 Jun 2002, José Fonseca wrote:
So to avoid being constantly checking for conclusion before asking to
process new entries we devised a different scheme:
- after adding new entries to the ring
- toggle the end flag of the previous last entry, so that the engine
will also
On Sat, 15 Jun 2002, Keith Whitwell wrote:
I also hope you do the toggle with a locked cycle so that you don't lose
any information..
Is this necessary if the toggle is really just a write? Jose, you're not
doing a read-modify-write operation on that flag are you?
That depends on the
On Sat, 15 Jun 2002, Leif Delgass wrote:
I forgot about that. The mach64 _does_ seem to update the word to
indicate the bytes of the DMA buffer remaining to be processed. You write
the number of bytes in the buffer and the DMA engine seems to decrement
this number as it processes the
On Tue, 18 Jun 2002, Linus Torvalds wrote:
So moving pages that way is definitely not cheap either. Hmm.
In fact, considering the cache and multi-CPU overhead, it's likely to be
faster to just memcpy() the damn thing from a regular cached mapping to an
existing AGP-mapped page. Which
On Thu, 4 Jul 2002, Tim Smith wrote:
(on my system glxgears behaves quite oddly with pageflipping enabled even
with only one; it has brief periods of seeming to animate slowly backwards,
but shows no significant change in framerate - it is the only app that I've
tried that behaves so
Is there any reason why the DRI tree isn't tracking the XFree86 CVS tree
more? On my Radeon 8500, the DRI tree apparently still doesn't do the Xv
extension correctly, even though XFree86 CVS has done it for ages (thanks
to Keith for getting the relevant bits off Gatos). So I have to have two
On Mon, 23 Sep 2002, Keith Whitwell wrote:
This is an open question for me. Does linux require an irq bh just to do a
wake_up_interruptible? Could/should we do something equivalent from the tophalf?
You can do pretty much anything from an interrupt context, as long as you
don't sleep or
On Thu, 26 Sep 2002, Dieter Nützel wrote:
Can we please change the IRQ code to not share the same IRQ with another
device?
Not up to us. It depends on the physical routing of the interrupt line on
the motherboard (often together with some amount programmability, but
Linux already tries to
On 29 Sep 2002, Jay Phelps wrote:
It looks to me like DRI claims to be starting up A-OK. However, glxinfo
reports no and gears FPS is as such that it's certainly not using DRI,
I'm including my log file for examination.
I had something similar the other week. XFree86.log showed that X had
On Tue, 1 Oct 2002, Keith Whitwell wrote:
Sounds like you aren't getting irq's, for some reason, and it is falling back
to busy waiting.
The question is why aren't you getting irq's?
Keith, are you even asking the kernel to look up (and possibly enable) the
irq for you?
The magic word
On Thu, 3 Oct 2002, Keith Whitwell wrote:
Would the appropriate place to call 'pci_enable_device' be just after a
successful call to (deprecated) pci_find_slot() ?
That should work (but you should check for failure on the find, instead
of potentially trying to pass in a NULL pointer to
On Sun, 13 Oct 2002, Dieter Nützel wrote:
But maybe it is related to my 2.5.42-mm1 kernel. It do not include the latest
DRI CVS DRM code and DRI CVS DRM do not compile with this kernel.
Actually, you should be able to just use the in-kernel DRM code, since it
is actually up-to-date wrt
On Sun, 13 Oct 2002, David D. Hagood wrote:
Is it at DRM 1.6.0 release?
It's up-to-date wrt all the drivers in CVS, and yes, for radeon the
current version is 1.6.0.
I was looking at running 2.5.x, since that
would seem to be a better fit to an SMP machine than 2.4.19,
On Sun, 13 Oct 2002, Dieter Nützel wrote:
But I didn't get this with 2.4.19/2.4.20-preX plus DRI CVS DRM module.
Hmm.. I'm looking at the diff beween DRI CVS and the kernel tree, and all
of it is purely semantic or due to the workqueue stuff in 2.5.x (which is
also the reason why DRI CVS
On Wed, 30 Oct 2002, José Fonseca wrote:
But it doesn't seem I can get away of assembly due to the exception
table. So the only way is to do it portably is to call __copy_user
inside my routine for every read, or do you have any other suggestion
you can give me?
If you want to do this a
On Thu, 31 Oct 2002, Keith Whitwell wrote:
On voodoo-1, even vertices that aren't snapped to 1/16th(?) subpixel coords
will crash it... Hmmm, you can't do fp in the kernel, right?
You _can_ use FP, but you have to jump through hoops to do so, especially
if you're in an asynchronous
On Wed, 20 Nov 2002, Dieter Nützel wrote:
Am Mittwoch, 20. November 2002 00:55 schrieb Ian Molton:
Linus updated 2.5.48 with Brian's latest DRM r200 stuff so I should do
some testing.
No go so far.
Modules are somewhat broken in 2.5.48.
One approach is to not use modules, just
On Wed, 20 Nov 2002, Dieter Nützel wrote:
Linus, Alan are you running SMP during your tests?
Yup. I'm running with a dual P4 HT (ie 4 virtual CPU's to software), and I
check with glxgears and the commercial tuxracer with a Radeon 8500. I've
also verified it on a UP machine with a Radeon 7500.
On Wed, 20 Nov 2002, Dieter Nützel wrote:
Can you please try ipers and isosurf from the Mesa-Demo package, too?
Q3A and UT are sometimes broken even if the above works right.
Well, I don't have the 3D apps, which is why I test with glxgears and
tuxracer (the first because it's th eonly GL
On Wed, 20 Nov 2002, Dieter Nützel wrote:
It's _really_ really slow, though, reporting a frame rate of 1.95 - 2.0
fps or so when viewing the thing (whatever it is) head on.
What do you get with LIBGL_DEBUG=verbose?
glinfo?
GL_VERSION: 1.4 Mesa 5.0
GL_EXTENSIONS: GL_ARB_depth_texture
On Thu, 21 Nov 2002, Dieter Nützel wrote:
GL_RENDERER: Mesa X11
GL_VENDOR: Brian Paul
Yeah, that seems to be true for the mesa test programs I installed.
Doing a regular glxinfo shows
OpenGL renderer string: Mesa DRI R200 20021009 AGP 4x x86/MMX/SSE TCL
On Thu, 21 Nov 2002, Dieter Nützel wrote:
Option AGPFastWrite 1
This just makes the machine lock up for me at X startup.
Option EnablePageflip
But this brings glxgears up to 2420 fps. Whee.
Linus
---
Guys,
I'm following the DRM kernel changes, and over the last few days code
appeared that I really don't think should be in the kernel, and that I
really don't want to merge.
The problem appears to be that the DRM people are used to using semaphores
to protect kernel data structures. That is
On Sun, 1 Dec 2002, Linus Torvalds wrote:
The problem appears to be that the DRM people are used to using semaphores
to protect kernel data structures. That is WRONG.
Follow-up, just in case somebody asks what are semaphores there for
then?
There are reasons to use semaphores
On 1 Dec 2002, Michel Dänzer wrote:
Actually, I did that because I thought send_sig_info() or kfree() might
not be interrupt safe.
Signals are commonly sent from interrupts: kill_fasync() is quite commonly
supported by many device drivers, and the resulting SIGIO is almost
universally sent
On Tue, 3 Dec 2002, Brian Paul wrote:
Otherwise, by using a generic format like GL_RGB the user is indicating
that he doesn't especially care. In this case, I think the driver should
lean toward the higher quality texture formats.
Why? I don't understand this reluctance to just admit that
On Tue, 3 Dec 2002, magenta wrote:
Ugh. The internalFormat is itself a hint. If the programmer cares about
how much storage is used or the quality, he/she should use GL_RGB4, GL_RGB8,
GL_RGB16, etc.
Oh yeah. Heh.
Oh, NO! No Heh.
The whole argument about if the programmer cares
On Tue, 3 Dec 2002, magenta wrote:
User preferences are an entirely different matter. I totally agree that
the user should be able to override default behaviors, but environment
variables are such a crappy way of doing this.
Why? Environment variables are in many ways more powerful than
On Thu, 5 Dec 2002, magenta wrote:
Well that sucks. I guess I'd never be able to enable super-sampled FSAA
with your wrapper on my R100. Even though I CAN do it with a driver-based
tweak utility on some other operating system.
But it's not even supported in the DRI driver on the
On Thu, 5 Dec 2002, magenta wrote:
- FSAA _cannot_ be done by a wrapper. End of discussion. It needs driver
explicit support for it. It's not a select one default value when
presented a choice kind of passthrough thing.
Why not?
Have you seen what the different FSAA cards can
On Thu, 12 Dec 2002, Alan Hourihane wrote:
On Thu, Dec 12, 2002 at 02:50:39PM +0100, Dieter Nützel wrote:
Some apps only run smooth with 2.5.49+ kernels due to Linus latest work.
Nothing of it in XFree or DRI, yet.
Linus should submit it here for inclusion - simple. I doubt any of us
On Wed, 18 Dec 2002, magenta wrote:
By implementing S3TC without a patent license, the DRI team would be
opening the DRI project up for potential litigation.
On the other hand, by being too timid, the DRI team can also eventually
doom itself to obscurity. If everybody else supports S3TC, and
On Wed, 18 Dec 2002, magenta wrote:
Also, what about doing hardware-only support, and just breaking for
software fallback? Then it'd be up to the hardware (which ostensibly has a
license) to implement the algorithm.
That sounds like a good approach (and almost certainly acceptable for
Ok,
I'm a bit bitter, because I just spent a long time chasing down a kernel
bug that didn't turn out to be a kernel bug at all.
I started seeing that strange SIGSEGV with programs that use dri, and it
happened right after the SIGFPE that tested for XMM support. As it
happens, I've done some
On Thu, 9 Jan 2003, Brian Paul wrote:
Josh Vanderhoof informed me that 16, not 32, should be added to ESP at the end
of that routine. I've checked in this change.
Actually, you should just remove it entirely, since the LEAVE will do the
right thing (which is why it worked AT ALL originally
On 19 Feb 2003, Alan Cox wrote:
copy_from_user sorts out the whole thing itself. In general __copy_from_user and
verify_area
isnt a win, except if you do lots of small copies to/from the same area, which is
often
a bad idea anyway.
It _can_ be a good idea, though.
In particular, it's a
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
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
On Wed, 26 Feb 2003, Sven Luther wrote:
Yes, and you have to divide the fb memory in two, one for each head, or
something such, and each head will have its separate offscreen memory
manager, possibly using different screen strides.
Side note: I know that what people are mostly talking about
Heh, offtopic.
On Thu, 27 Feb 2003, Nicholas Leippe wrote:
IMO it may as well be ignored. There's no sense in keeping up with the
Jones's if the Jones's aren't doing anything fundamentally worthwhile. What
great new advantage does Longhorn tout to provide?
I think the great advantage
On Fri, 28 Feb 2003, Ian Molton wrote:
The human eye cant do better than 9bpp, and thats in its most sensitive
colour, green.
That wasn't true the last time somebody claimed this, and it's not true
now.
Why do people keep on repeating this crap?
No, the human eye may not be able to
On Sat, 1 Mar 2003, Keith Whitwell wrote:
Interesting you mention it. This is what Brian I've done in the Mesa
embedded branch -- layered the radeon dri driver on top of fbdev. I can also
build regular DRI drivers from a minimal tree sane set of makefiles.
Personally, I'd rather see
On 2 Mar 2003, Alan Cox wrote:
Thats one reason I'd love to see the C++ framework proposed. Hell I can
draw triangles on my SiS6326, its just there isn't a way to plug that
code into an existing framework yet.
I think this is the perfect example of hard to get into. A person who
knows what
On 2 Mar 2003, Alan Cox wrote:
Since XFree 4.0 you don't have to touch the core code, you
don't have to duplicate a ton of stuff and you don't need
to know zip about DDX, MI and the other core layers.
Yeah, I don't think regular X is problematic. The Xv stuff used to be
quite messy, but
On Sat, 1 Mar 2003, Jon Smirl wrote:
I'd like to see Linux turn XFree inside out. Instead
of OpenGL/DRI being bolted onto X, bolt X onto
OpenGL/DRI.
It might not even be that painful to try. X largely should support things
like that simply thanks to the fact that people have already
On Sat, 1 Mar 2003, Allen Akin wrote:
This is largely because there's a *much* greater emphasis on performance
in the 3D world than in the 2D world. There's too much competitive
advantage to be gained by exposing hardware peculiarities and by
avoiding certain kinds of abstraction.
Well,
On Sun, 2 Mar 2003, Andreas Stenglein wrote:
I pulled the powercable, waited, plugged the cable,
startet the box up again and tried without dri:
Xserver recycles well!
I have apparently seen something like this even on 2.5.x. What kernels
have you tried?
The symptoms I saw were kernel
On Sun, 2 Mar 2003, Linus Torvalds wrote:
The _second_ DRI-enabled X startup caused problems, even if I had done
multiple non-DRI X sessions in between. This is what makes me think that
the DRI kernel modules keep some history around that they shouldn't. And
maybe the problem is hidden
On Tue, 4 Mar 2003, Philip Brown wrote:
Does this thunking happen at the native OS level, or in the linux drm
code itself?
Each user has to thunk on its own, since nobody else even knows what the
ioctl stuctures are.
Moral of the story: avoid ioctl's. _Especially_ avoid ioctl's with
On Wed, 5 Mar 2003, Nicholas Leippe wrote:
I agree with Jose--let the features used be chosen on technical merit, not
just somebody's whim. Imo, it is far too premature to just discard this or
that feature of C++.
If people decide to go with C++ (which I don't disagree with per se),
On Wed, 5 Mar 2003, [iso-8859-15] José Fonseca wrote:
Actually virtual code will be used extensively, especially in the Mesa
wrapper classes, but there is no other way around it - the current Mesa
C driver callback table has more than 112 functions.
Oh, I agree that you should not avoid
I just finished a merge of the current DRI CVS tree kernel parts into
2.5.x. I've not done one of these in a while, so sadly the merge ends up
being several totally unrelated things (i830 irq updates, the lock context
fixes, and various random smaller things).
I've pushed the result out, and
On Sun, 30 Mar 2003, Dave Jones wrote:
This bit seems to be backing out a memleak fix..
Well, yes and no. I looked at the code, and decided that the memleak fix
was hottibly bogus.
Look at how the allocations are done inside the loop: they are INSIDE A
LOOP.
Look at what happens with the
On Sat, 29 Mar 2003, Linus Torvalds wrote:
I tested on radeon, and tested by compiling all the drivers into the
kernel. Looked good as far as I can tell. Although I have to say that the
current DRI CVS tree has a lot of flashing textures on the commercial
tuxracer thing.
I also checked
On Sun, 30 Mar 2003, Keith Whitwell wrote:
The server reset bug that was fixed was radeon-specific. I've been trying
with the dri trunk can't reproduce the hang on one 845 box, though I've got
another can try that too.
Ok. I've tried to figure out what triggers it - it doesn't always
On Sun, 30 Mar 2003, Keith Whitwell wrote:
The server reset bug that was fixed was radeon-specific. I've been trying
with the dri trunk can't reproduce the hang on one 845 box, though I've got
another can try that too.
In case you care, this is a shuttle mini-pc:
00:00.0 Host bridge:
On 4 Apr 2003, Michel Dänzer wrote:
But why does this cause a hang?
I'm not sure, maybe some kernels and/or machines don't like the
interrupt being enabled without the handler being installed. I couldn't
reproduce the problem on my Macs.
Let's walk through it. First, the setup conditions:
On Thu, 29 May 2003, Keith Whitwell wrote:
The lock doesn't seem to be 'fair' like that - in practise it isn't transfered
to the waiting process (unless you do a sched_yield() after unlocking).
Indeed. If you want fairness, you need to code for it explicitly. It's not
hard per se, but it
On Fri, 30 May 2003, Denis Oliver Kropp wrote:
In the kernel part of Fusion (our IPC API) I'm currently calling yield()
after unlocking a long-time lock. Maybe you have some hints before I'm
working on that issue.
You really shouldn't unconditionally yield. That just tells the kernel
that
On Thu, 29 May 2003, Ian Romanick wrote:
You're right. We do _really_ want to use futex'es. However, I don't
think they're available on *BSD or Solaris.
No. But you don't want to use them directly anyway, they're at the wrong
level. I haven't checked what glibc does, but I bet it has a
Have others seen this? Current DRI CVS tree, current 2.5.x kernel (which
is pretty current kernel-module-wise, the only difference to the current
DRI tree _seems_ to be the documentation updates).
Same thing happens with an older DRI CVS tree too (with new kernel
modules), for that matter.
On Fri, 30 May 2003, Linus Torvalds wrote:
Modulo that, X is happy, with no error messages apart from a mention of
the irq issue in the logs up until the lockup:
(II) RADEON(0): [drm] failure adding irq handler, there is a device already
using that irq
[drm] falling back
On Mon, 2 Jun 2003, Keith Whitwell wrote:
Under what circumstances does this actually happen? First 3d app run? Even
something like 'glinfo'?
I don't even get a desktop - the thing hangs at initialization time
(probably when clearing the screen.
My hardware may actually have gone bad,
On Mon, 2 Jun 2003, Ian Romanick wrote:
I think you would be fine with multiple modules, but I think it would
break if you had multiple drivers built into the kernel. I'm not sure
about that, though.
Yes.
The reason for DRM(xxx) is that I personally _require_ that built-in
modules
On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote:
According with archives
(http://dri.sourceforge.net/doc/faq/architecture.html#DRM-SUB-DRIVERS),
Linus wanted the DRM drivers to be independent.
I wanted that because the old code was total crap, and the makefiles could
never get the
On Tue, 3 Jun 2003, David Dawes wrote:
Does this go any way towards explaining why it seems to be getting harder
and harder to build modules outside of the kernel source tree while
still leveraging the kernel build mechanism?
No. That is explained by the inevitable lack of testing, I think.
On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote:
IIUC, at least for modules, the symbols which we want to make available
to other modules usually have to be specificaly declared (with
EXPORT_SYMBOL). Therefore each module it's own namespace, i.e., two
different modules with some public
On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote:
Quite frankly, looking at the current DRI tree, there's not a lot of
code like this there that I can see. Almost every single library
function has intimate details about the hardware through macro
expansion.
By the
[ Finally got some debugging time for the other DRI problem I've seen,
namely hugely flashing textures in tuxracer on i830, but _only_ iff MTRR
support is compiled into the kernel ]
On Wed, 14 May 2003, Linus Torvalds wrote:
reg00: base=0x ( 0MB), size=1024MB: write-back, count
On Tue, 3 Jun 2003, David Dawes wrote:
So, my question is whether the new kernel build mechanism is intended
to allow this type of thing, or did it work before more by accident than
design?
Hmm.. Sounds accidental, but it might be a good idea to contact
Sam Ravnborg [EMAIL
On Wed, 4 Jun 2003, Dave Jones wrote:
This was exactly the reason I hesitated when you first suggested that I
did exactly that for agpgart, but I figured you knew best...
It's worked pretty well for AGP, and it sure as hell cleaned stuff up.
It was a suggested thing for DRI too a _loong_
On Tue, 3 Jun 2003, Linus Torvalds wrote:
[ Finally got some debugging time for the other DRI problem I've seen,
namely hugely flashing textures in tuxracer on i830, but _only_ iff MTRR
support is compiled into the kernel ]
I've got some more information, including a workaround..
I
On Tue, 10 Jun 2003, Dave Jones wrote:
(In fact the agpgart code
really doesn't handle this concept at all due to the extensive usage
of aperture type macros/typedefs).
Why _is_ that AGP code using those silly thing in the first place?
I actually looked at
On Wed, 11 Jun 2003, Sven Luther wrote:
And we will throw out all our existing hardware and run buying
PCI-Express enabled ones, right ?
Yeah, no, I don't believe it. Hardware infrastructure has incredible
staying power. See how even ISA has only been _really_ dying in the last
two years
On Fri, 13 Jun 2003, Roland Scheidegger wrote:
(This could be related to the same bug as the one seen in nwn, as
decreasing the cmd_buf size fixes the problem for me just as well,
though I still have no idea why).
I wonder if this is related to the flickering problem I saw on i845, and
On Fri, 13 Jun 2003, Philip Armstrong wrote:
Fwiw I see these symptoms too on a radeon mobile equipped laptop
running UT200x -- but only if the original X desktop size is the full
1600x1200 (running UT at 800x600). If I start X at 800x600 and then
start UT, I get no texture flickering at
On Mon, 30 Jun 2003, [iso-8859-15] José Fonseca wrote:
Half done. For everybody eager to get the latest DRI trunk do something
like:
rsync -avz --delete rsync://mefriss1.swan.ac.uk/dri/ HEAD/
Thanks. CVS was getting to be useless.
Linus
On Thu, 17 Jul 2003, Dave Airlie wrote:
I think the latest Linus update should fix the i810 issue that was
reported here, but there may still be some hiding, (that was the one with
the key being 0) but I think any probs in 2.6.0-test1 we should also
see in the the DRI tree...
test1
Ok,
I just did another kernel merge to pick up the i810 compatibility bits,
and decided it is time to try to merge back some of the stuff that has
accumulated in the standard kernel and that makes it more painful than
necessary to examine the diffs for differences.
This is mostly whitespace
Ok, this is pretty off-topic, but I'm wondering what the status is for
open-source support of 3D-capable drivers for such studly monitors as the
IBM T221.
Yes, it's still expensive as hell, but it isn't nearly as bad as it was a
few years ago when it was very limited availability, and cost USD
Is Xv output supposed to work on i830-based setups? I seem to get just a
blue overlay when I try using mplayer or similar. Normal shm-X11 works
fine, but both Xv and SDL do not (SDL will try to use Xv - but I checked
it just in case it was an mplayer Xv usage bug. I can't imagine that both
the
On Tue, 2 Sep 2003, Jon Smirl wrote:
Having used CVS and BitKeeper, BitKeeper is way better.
I will just add a big Amen, Brother! to that.
Yes, BitKeeper has license issues, and some people won't touch it. But
there are CVS/SVN gateways for that, and the kernel people (who I think
tend to be
On Wed, 3 Sep 2003, Thomas Emmel wrote:
Thanks a lot for your help. I have already loaded it via rsync from
jose's mirror. Approx. 10 times faster than CVS...
rsync from jose has made it at least _possible_ to follow DRI development.
However... It's really a sucky thing to use. It means
1 - 100 of 263 matches
Mail list logo
