On Tue, Dec 09, 2003 at 01:24:16PM -0600, Ryan Underwood wrote:
Thanks for the insight. Is this already something that has been
extensively looked at without success, or would it be worth my time to
dig into the code and try to find the cause? I've thought about it, but
afraid that I will
Hi,
I briefly tried the DRI trunk after the newmesa merge last night. In
flightgear with TCL enabled the old lighting problem seems to be back.
Everything is too dark, but banking to one side makes things brighter.
There is another problem with Torcs that looks like texture coordinates
are
On Tue, 09 Dec 2003 22:50:54 -0800
Eric Anholt [EMAIL PROTECTED] wrote:
[snip]
P.S. Felix, I still have testing that r128 diff on my TODO, sorry for
not trying it yet.
No problem. It's not really a priority and nothing else depends on it. I
was just starting to forget about it myself, so I
On Tue, 09 Dec 2003 17:53:14 -0600
David D. Hagood [EMAIL PROTECTED] wrote:
Alan Hourihane wrote:
I'm going to merge the newmesa branch to the trunk in a few moments.
I've giving people a heads up that I'm going to delete the xc/extras/Mesa
directory and insist on people checking out a
Felix Kühling wrote:
On Tue, 09 Dec 2003 17:53:14 -0600
David D. Hagood [EMAIL PROTECTED] wrote:
Alan Hourihane wrote:
I'm going to merge the newmesa branch to the trunk in a few moments.
I've giving people a heads up that I'm going to delete the xc/extras/Mesa
directory and insist on people
Felix Kühling wrote:
Hi,
I briefly tried the DRI trunk after the newmesa merge last night. In
flightgear with TCL enabled the old lighting problem seems to be back.
Everything is too dark, but banking to one side makes things brighter.
Can you remember what changed to fix that problem last time?
I just went through the hardware I have on FreeBSD trying the newmesa
DRI, testing with glxgears and tuxracer, and the mesa demos reflect,
gloss, and tunnel.
The r200 system had 4.3.99.15 server, 4.3.0 libGL, and newmesa GL
drivers. 1600x1200x16 screen. The other tests were done on another
On Wed, Dec 10, 2003 at 09:03:34AM +0200, Ville Syrjälä wrote:
On Tue, Dec 09, 2003 at 01:24:16PM -0600, Ryan Underwood wrote:
Thanks for the insight. Is this already something that has been
extensively looked at without success, or would it be worth my time to
dig into the code and
Felix Kühling wrote:
It would be annoying for people with dialup connections if make required
access to a remote CVS repository.
And how would that be any different than syncing up with the main DRI
CVS repo? If you are building one from CVS, you may as well get the
other from CVS as well.
Am Mittwoch, 10. Dezember 2003 02:04 schrieb Alan Hourihane:
On Tue, Dec 09, 2003 at 04:54:24PM -0800, Eric Anholt wrote:
On Tue, 2003-12-09 at 16:34, Alan Hourihane wrote:
On Tue, Dec 09, 2003 at 04:14:09PM -0800, Eric Anholt wrote:
On Tue, 2003-12-09 at 15:52, Alan Hourihane wrote:
Am Sonntag, 10. August 2003 9:39 schrieb Andreas Stenglein:
trivial...
fixes some typos in the radeon driver
[r100_sanity_typo_patch1.txt (text/x-patch)]
diff -ru HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c \
Am Dienstag, 09. Dezember 2003 11:15 schrieb Keith Whitwell:
Jon Smirl wrote:
My current thinking on this is to do it the DRM driver but store the
allocation
data in normal system RAM. This would allow the allocation
routines to function without touching the framebuffer.
I would
On Wed, Dec 10, 2003 at 02:46:27PM +0100, Dieter Nützel wrote:
Am Sonntag, 10. August 2003 9:39 schrieb Andreas Stenglein:
trivial...
fixes some typos in the radeon driver
[r100_sanity_typo_patch1.txt (text/x-patch)]
diff -ru HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c
On Wed, 10 Dec 2003, Ryan Underwood wrote:
They're not available anymore :( It's a real shame since they seemed to be
quite friendly towards open source developers at one point. I can almost
understand that they don't want to release any parhelia docs but I don't
understand why they
Am Mittwoch, 10. Dezember 2003 15:12 schrieb Alan Hourihane:
On Wed, Dec 10, 2003 at 02:46:27PM +0100, Dieter Nützel wrote:
Am Sonntag, 10. August 2003 9:39 schrieb Andreas Stenglein:
trivial...
fixes some typos in the radeon driver
[r100_sanity_typo_patch1.txt (text/x-patch)]
On Wed, Dec 10, 2003 at 08:52:03AM -0800, Linus Torvalds wrote:
Must be some new management over there... *sigh*
Never attribute to malice what can be sufficiently explained by
laziness or stupidity.
^
Why do you think I mentioned management? :)
But when it comes to
On Wed, Dec 10, 2003 at 06:37:29PM +0100, Dieter Nützel wrote:
Am Mittwoch, 10. Dezember 2003 15:12 schrieb Alan Hourihane:
On Wed, Dec 10, 2003 at 02:46:27PM +0100, Dieter Nützel wrote:
Am Sonntag, 10. August 2003 9:39 schrieb Andreas Stenglein:
trivial...
fixes some typos in the
Am Mittwoch, 10. Dezember 2003 20:13 schrieb Alan Hourihane:
On Wed, Dec 10, 2003 at 06:37:29PM +0100, Dieter Nützel wrote:
Am Mittwoch, 10. Dezember 2003 15:12 schrieb Alan Hourihane:
On Wed, Dec 10, 2003 at 02:46:27PM +0100, Dieter Nützel wrote:
Am Sonntag, 10. August 2003 9:39 schrieb
David D. Hagood [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
It would be annoying for people with dialup connections if make required
access to a remote CVS repository.
And how would that be any different than syncing up with the main DRI
CVS repo? If you are building one from CVS, you
On Wed, Dec 10, 2003 at 12:25:36PM -0600, Ryan Underwood wrote:
In an open software architecture like the DRI, we should do our best to
support proprietary vendors when they give us the means to do so, but
all the pissing and moaning about what they will and won't do should go
either to
Am Montag, 20. Oktober 2003 23:31 schrieb Keith Whitwell:
Ian Romanick wrote:
Roland Scheidegger wrote:
Slightly OT, but here's an article comparing XiG Summit, dri cvs and
the ATI driver on a radeon 9000pro.
http://homepage.hispeed.ch/rscheidegger/atilinux_oct03/ati_linux_comp_oc
Are there any plans for the Savage drivers to support the VBLANK IOCTLs
in the near future?
Thanks.
--
- Steve http://www.nexusuk.org/
*** Presented in DoubleVision (Where Drunk) - Futurama ***
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=967
[EMAIL PROTECTED] changed:
What|Removed |Added
Martin Spott wrote:
You would sync manually and not every time you call 'make',
Whether you sync'ed every time or not would depend upon the way the make
rule was written - if the rule is tied to the existance of the
directory, then the pull would happen the first time only.
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=967
--- Additional Comments From [EMAIL PROTECTED] 2003-12-10 19:56 ---
Created an
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=967
--- Additional Comments From [EMAIL PROTECTED] 2003-12-10 20:07 ---
Created an
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=967
[EMAIL PROTECTED] changed:
What|Removed |Added
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=967
--- Additional Comments From [EMAIL PROTECTED] 2003-12-10 20:15 ---
Don't use the
I'm trying to valgrind my application and in the process DRI :-),
However I can't get over the Mesa MMX checks, is there any env variable I
can set so Mesa doesn't do all the stuff that requires SIGFPE and I can
force it to use a certain type of instruction set?
I've been just setting
29 matches
Mail list logo
