Adam K Kirchhoff wrote:
A few weeks ago there was some discussion about the fact that the
post-texmem merge code has broken Neverwinter Nights.
I believe you are speaking about radeon/r200?
The post-texmem merge did not break Neverwinter Nights - it just made
some errors which were there before
José Fonseca wrote:
(II) RADEON(0): [drm] created radeon driver at busid PCI:1:0:0
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0c7
(II) RADEON(0): [drm] mapped SAREA 0xe0c7 to 0x40023000
(II) RADEON(0): [drm] framebuffer handle = 0xd800
(II) RADEON(0): [drm] added 1 reserved
I can no longer get bttv and dri (dri cvs) to work simultaneously with
kernel 2.4.21. If dri is enabled (and working) then v4l-conf will
complain cannot allocate memory. Kernel log will show:
bttv: vmalloc_32(8519680) failed
bttv: vmalloc_32(8519680) failed
bttv: vmalloc_32(8519680) failed
bttv:
Roland Scheidegger wrote:
I can no longer get bttv and dri (dri cvs) to work simultaneously with
kernel 2.4.21. If dri is enabled (and working) then v4l-conf will
complain cannot allocate memory. Kernel log will show:
bttv: vmalloc_32(8519680) failed
bttv: vmalloc_32(8519680) failed
bttv
Roland Scheidegger wrote:
José Fonseca wrote:
(II) RADEON(0): [drm] created radeon driver at busid PCI:1:0:0
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0c7
(II) RADEON(0): [drm] mapped SAREA 0xe0c7 to 0x40023000
(II) RADEON(0): [drm] framebuffer handle = 0xd800
(II) RADEON(0
Ian Romanick wrote:
Forge wrote:
I think a detail is being overlooked here.
R200 does not have 3 TMUs per pipe. R200 is 4 pipes, 2 TMUs each. Only
R100 (Radeon) and RV200 (Radeon 7500) and their derivatives use the
2*3 pipes/TMUs layout.
Does anyone have any evidence to the contrary?
No.
Slightly OT, but here's an article which compares the dri drivers, ATI's
binary driver and the driver from XiG Summit on a 9000pro:
http://homepage.hispeed.ch/rscheidegger/atilinux/ati_linux_comp.html
Roland
---
This SF.net email is
Michael wrote:
Roland Scheidegger wrote:
Slightly OT, but here's an article which compares the dri drivers,
ATI's binary driver and the driver from XiG Summit on a 9000pro:
http://homepage.hispeed.ch/rscheidegger/atilinux/ati_linux_comp.html
Have you tried comparing the performance between dri
Paul Heldens wrote:
glxinfo
...
direct rendering: Yes
...
OpenGL renderer string: Mesa DRI R200 20030328 AGP 1x x86/MMX+/SSE2 TCL
OpenGL version string: 1.3 Mesa 5.0.1
...
When I try to start:
./nwn
Error
The NWN forum says this has to do with impropper initialisation of
opengl subsystem. ?
Keith Whitwell wrote:
Bertrand Lamy wrote:
hello everybody
I have found 3 bugs in the DRI driver. See the attached file for
description. Each program is the 'minimal' code to get the bug.
I also give my computer configuration.
I am quite sure that the bugs lie in the driver cause:
- it does
Ian Romanick wrote:
Roland Scheidegger wrote:
These changes (not sure if the cvs I got has all of them, got
r200_state.c version 1.16) change lighting considerably in NWN.
However, it's still not correct, it is too dark now.
I've uploaded a new picture (especially weird is IMHO the highlighted
Felix Kühling wrote:
I don't think this is a matter of the chip revision but rather what the
card manufacturer puts around the chip, like DDR vs. SDR RAM and 64-bit
vs. 128-bit memory interface and at which frequencies the chip and
memory are clocked.
Speaking of ram width, would it be possible to
Ian Romanick wrote:
Korosi Akos wrote:
Section Device
Identifier Videocard0
Driver radeon
VideoRam131072
Option AGPMode4
#Option AGPSize128
# === disable PnP Monitor ===
#Option NoDDC
# === disable/enable
Linus Torvalds wrote:
The thing is a 3840x2400 pixel monster, and to drive it at reasonable
frequencies you actually need to support a quad DVI setup where it
looks basically like four monitors running at 1920x1200. And from
what I can gather by googling, the outputs need to be synchronized,
Is someone looking at the NWN issues with R200 (and probably R100 too)?
There is still random flickering, and the lighting isn't correct neither
(both issues only with TCL). Keith changes (end of july) changed the
lighting, but now it basically looks like some light is completely missing.
This
Is someone looking at the NWN issues with R200 (and probably R100 too)?
There is still random flickering, and the lighting isn't correct neither
(both issues only with TCL). Keith changes (end of july) changed the
lighting, but now it basically looks like some light is completely missing.
This is
Daniel Vogel wrote:
Uhm, I wonder if the latest demo patch also lifts it...
No.
I respectfully disagree. The 2206 demo works just fine without s3tc here :-)
The UT2004 demo will work without S3TC support... and FWIW, without OpenGL
support as well as we're including a software renderer again.
cvs trunk will no longer compile for me:
gcc ... xmlconfig.c
xmlconfig.c:268:29: warning: ISO C does not permit named variadic macros
xmlconfig.c:280:27: warning: ISO C does not permit named variadic macros
xmlconfig.c:294:27: warning: ISO C does not permit named variadic macros
xmlconfig.c: In
Felix Kühling wrote:
Some quick googling shows this looks like it's some compatibility
problem with expat. Currently, I have installed expat 1.95.4 (SuSE 8.1,
gcc 3.2).
Am I just supposed to upgrade expat? That's no problem, but aren't all
those expat 1.95.x releases supposed to be source (and
Martin Spott wrote:
Alex Deucher [EMAIL PROTECTED] wrote:
I just committed a major rework of mergedfb to CVS. almost all of the
code is now in radeon_mergedfb.c/h. I also committed Hui's latest code
drop from xfree86 CVS. Let me know if anyone has any problems.
I'm fine with running the 'new'
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_oct03.html
And to get this fully on-topic, is there a specific reason why the dri
driver is quite a bit slower (up to
Michel Dnzer wrote:
On Thu, 2003-10-16 at 03:49, Roland Scheidegger wrote:
And to get this fully on-topic, is there a specific reason why the dri
driver is quite a bit slower (up to 50% in some subtests) in
SpecViewPerf compared to the cvs version of july?
I wonder if it could be related
Keith Whitwell wrote:
Alex Deucher wrote:
As I recall KDE preloads libGL for some reason. that might have
something to do with it.
If you make sure that the old driver.so file is removed, not
overwritten, there shouldn't be any problem, as existing open
filehandles won't then see any
Keith Whitwell wrote:
The problem is (probably) due to excessive flushing introduced by the
changes Ian referenced. I had time to put together a patch, but at that
point was having real issues getting CVS to compile. These are probably
at my end, but before they were resolved I got
Michel Dnzer wrote:
Also, regarding the rendering errors at 2048, I looked at the clearing
code in the DRM, but nothing really seemed amiss. I don't see why it
would work at resolutions up to 2047, but not at 2048. Does anyone
else have thoughts on that?
My best bet is still an off-by-one
Ronny V. Vindenes wrote:
Something in the last week or two broke the r200 driver. After I cvs
update'ed and recompiled yesterday, I get this error:
(EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020
(EE) RADEON(0): GetBuffer timed out, resetting engine...
(EE) RADEON(0): RADEONCPGetBuffer: CP
Chris Ison wrote:
Its the same situation in GL apps (which I did mention, I only used
glxgears as the prime example cause it should be heeps faster
considering it doesn't do texturing).
In general I agree. However, it does usefully suggest that Chris isn't
getting hardware acceleration. He
Michel Dnzer wrote:
On Thu, 2003-12-04 at 11:48, Mike A. Harris wrote:
THe first step to me, would be to oprofile things, and find where
the bottleneck is, then try to determine why.
Good idea, but beware that the gprof output was rather confusing when I
first saw this problem, the time would
Here are some patches (all against current Mesa CVS) to enable s3tc on
radeon and r200 based cards (radeon is untested but it's really exactly
the same as on the r200 so without stupid copypaste errors there's hope
it works...). These radeon and r200 patches should IMHO (IANAL) be
Jacek Popawski wrote:
On Thu, Dec 18, 2003 at 02:43:09AM +0100, Roland Scheidegger wrote:
and I don't know if any open-source
compressors exist which could easily be included in mesa
Adam K Kirchhoff wrote:
So I decided to give 2.6.0 a shot this morning :-)
My Radeon 8500 (which previous worked with 2.4.22) refuses to enable
direct rendering:
(WW) RADEON(0): [agp] AGP not available
(II) RADEON(0): [drm] removed 1 reserved context for kernel
(II) RADEON(0): [drm] unmapping
Ian Romanick wrote:
Since I'm not a lawyer, I'm not going to comment on any of the IP
legality of this patch. I am in no way offering any form of legal
advice. I do have a comment about the correctness of it that may also
apply to similar future (i.e., FXT1) patches.
Roland Scheidegger wrote
Dieter Nützel wrote:
Am Freitag, 26. Dezember 2003 17:46 schrieb Adam K Kirchhoff:
Just wanted to say that Roland's S3TC patches work incredibly well on my
8500 with NWN. I can now get just as high quality textures with the DRI
drivers as I do with the FireGL drivers :-)
Roland, do you have a
Dieter Ntzel wrote:
Am Sonntag, 28. Dezember 2003 17:08 schrieb Adam K Kirchhoff:
On Sun, 28 Dec 2003, Jacek [iso-8859-2] Popawski wrote:
On Sun, Dec 28, 2003 at 10:23:17AM -0500, Adam K Kirchhoff wrote:
Now that there are patches available to support S3TC compressed
textures on Radeon cards,
Felix Kühling wrote:
A patch is attached. The order in which state atoms are emitted now is
pretty arbitrary. It may be worth finding out exactly which permutations
of state changes trigger the lockup. In the interest of security we
could detect them in the DRM driver and emit a 3D idle to prevent
Based on the idea of Felix Kühling that the order in which state atoms
are emitted might be important on the radeon, I thought maybe it might
be important on the r200 as well, even though there are no lockups.
With the attached patch indeed the random color flashings seem to be
gone (at least
Yes you're right, I just used fixed numbers matching those in
r200_hw_state in r200_context.h. (Note this will also try to emit mtl[1]
and pix[2-5] which is unncessary, as they are never ALLOC_STATE'd nor
used, but I guess it shouldn't hurt as they'll never have their dirty
flag set.)
Attached
Jesse Merriman wrote:
Alex Deucher wrote:
hmmm... if both agpgart and savage are loaded before X starts, I'm not
sure what your problem would be. what does your kernel log or dmesg
say when you load the modules?
Here's the end of my dmesg:
Linux agpgart interface v0.100 (c) Dave Jones
savage:
Michel Dnzer wrote:
Finally some progress on this front! :)
I tracked down the lighting problems in the xscreensaver queens hack
to attenuation being broken. I noticed that the R200 DDK reference
driver does much more to handle it, in fact our driver doesn't seem
to enable it at all!
Michel Dnzer wrote:
Some minor lighting problmes still remain (I spotted 3 which might be
related though):
- selected doorways should be half-transparent, blue. Instead they are
anything from almost black to grey (depending on map)
- If the main character is selected, it should shine. There is
Michel Dnzer wrote:
BTW, I still get flickering in lightlab when enabling the object
specular colour, maybe it takes some more tweaking of the state atom
emit order, Andreas? :)
I don't think this one is related. Seems to be more like some overflow
problem, if the object shininess is slightly
Michel Dnzer wrote:
On Tue, 2004-01-13 at 14:51, Felix Khling wrote:
On Tue, 13 Jan 2004 14:38:37 +0100
Michel Dnzer [EMAIL PROTECTED] wrote:
On Mon, 2004-01-12 at 17:44, Michel Dnzer wrote:
There are still minor problems, e.g. in the xscreensaver endgame hack,
but those might be related to
Michel Dnzer wrote:
On Tue, 2004-01-13 at 21:12, Roland Scheidegger wrote:
Sure this is about timing?
No, the only thing I'm sure of is that _mesa_lookup_enum_by_nr()
reliably works around part of the problem here.
What I see in endgame is this:
Every few seconds, the colors change from orange
I've just had too much spare time and though it would be interesting to
see which mesa demos/tests have problems (lighting or otherwise), so
here are the results of all tests which did not run correctly (of course
quite a few tests wouldn't run at all due to missing arb_fp, arb_vp or
whatever
Brian Paul wrote:
cubemap: with hardware tcl inner sphere looks correct, outer cube
has only blue face, the others are missing, and texture is more
fuzzy (might be just a different lod bias?) compared to software
mesa. tcl_mode=0 is even worse: inner sphere everything is only
blue/white, outer
Dieter Nützel wrote:
stex3d:
the 3d texture fallback seems to be very slow. software mesa
seems to run about 2-3 times faster than hardware acceleration using the
fallback.
Not sure about that, but the TexCoord3 issue would also apply here.
Can you verify the clipping bug (with r200) when you
Dieter Nützel wrote:
cubemap:
with hardware tcl inner sphere looks correct, outer cube has
only blue face, the others are missing, and texture is more fuzzy (might
be just a different lod bias?) compared to software mesa.
tcl_mode=0 is even worse: inner sphere everything is only blue/white,
outer
Dieter Nützel wrote:
This also
seemed to cause a drop in glxgears performance (one of the few apps
which don't use texturing...) by a factor of 10 or so (but yes, it is
using hardware rendering).
No, not seen here (r200) without and with Andreas fix.
progs/demos
progs/demos 9899 frames in
Dieter Nützel wrote:
Dieter Nützel wrote:
stex3d:
the 3d texture fallback seems to be very slow. software mesa
seems to run about 2-3 times faster than hardware acceleration using the
fallback.
Not sure about that, but the TexCoord3 issue would also apply here.
Can you verify the clipping bug
Michel Dnzer wrote:
On Tue, 2004-01-13 at 23:28, Roland Scheidegger wrote:
Michel Dnzer wrote:
On Tue, 2004-01-13 at 21:12, Roland Scheidegger wrote:
Maybe not all necessary state is submitted?
Maybe, but that doesn't really explain my observations, does it?
Well for me there was no difference
Dieter Nützel wrote:
(needed for QuakeIII/rtcw, don't know about
rtcw:et). This time I haven't tested the r200 patch, only radeon so use
at your own risk.
Using 8/8/8 Color bits, 24 depth, 8 stencil display.
GL_RENDERER: Mesa DRI R200 20030328 AGP 4x x86/MMX+/3DNow!+/SSE TCL
Initializing OpenGL
Daniel Vogel wrote:
[replying to multiple people]
They also enable the old, undocumented, dead and buried GL_S3_s3tc
extension
http://oss.sgi.com/projects/ogl-sample/registry/S3/s3tc.txt
Yes, but everything there just says unknown - no compression format,
nothing interesting at all (except
Ian Romanick wrote:
Roland Scheidegger wrote:
pointblast: (both with hardware tcl and without) the points are
almost invisible. IIRC this was already mentioned some time ago to
be because all points are drawn with size 1 only.
Right. Could you try it again with this patch. You may need some
Ian Romanick wrote:
I know this is a breach of protocol, but I'd like to discuss the patch
that I have for this before attaching it to the bug report or committing
it.
In both the client-side and the server-side g_render.c I have created
some template macros for generating the GLX protocol
Roland Scheidegger wrote:
Ian Romanick wrote:
Roland Scheidegger wrote:
pointblast: (both with hardware tcl and without) the points are
almost invisible. IIRC this was already mentioned some time ago to
be because all points are drawn with size 1 only.
Right. Could you try it again
ok, here's another attempt, which uses an external dxtn library (patch
against current Mesa cvs trunk).
There is a new configuration option to enable the s3tc extension even if
the external library is not available (useful for games such as nwn,
ut2k3 which use precompressed textures), though
Roland Scheidegger wrote:
ok, here's another attempt, which uses an external dxtn library (patch
against current Mesa cvs trunk).
crap, forgot to attach the library.
Roland
txc_dxtn.tar.gz
Description: application/gunzip
Ian Romanick wrote:
Seems to be quite complicated. Though wouldn't it be a better idea to
figure out why it doesn't work in the first place? R200/RV250 should
support this, but apparently for some reason it doesn't work.
According to r200_reg.h, the chip should also be able to handle
Ian Romanick wrote:
Brian Paul wrote:
Brian Paul wrote:
Crap. I missed an aspect to this. The texmem manager explicitly
free's the data pointed to by texObj-DriverData when the texture's
swapped out of VRAM.
I'll fix things up ASAP.
OK, I think I've got it right now.
A longer term issue
Ian Romanick wrote:
I think the patch is not complete though, I believe you'd need to add
some missing values (like GL_FOG_COORDINATE_SOURCE, which can get used
in glFog[if]v if you have the FogCoord Extension to singlesize.c and
compsize.c), at least until before everything is converted to the
This one-byte patch fixes the endgame xscreensaver (both version 4.05
and 4.14).
Don't know if it's actually correct, but after looking at endgame with
gdb it looked like some likely necessary state updates were omitted.
Reversing the condition when to call the update material function fixes
Just noticed that there are other mesa tests which also don't work
correctly :-(.
redbook/alpha3D: nothing is shown, unless you keep pressing a - some
buffering problem?
redbook/polys: the 2nd and 3rd rectangle use the same pattern (that from
the 3rd poly). Looks like the driver can't handle
Keith Whitwell wrote:
Roland Scheidegger wrote:
This one-byte patch fixes the endgame xscreensaver (both version 4.05
and 4.14).
Don't know if it's actually correct, but after looking at endgame with
gdb it looked like some likely necessary state updates were omitted.
Reversing the condition
Michel Dnzer wrote:
On Thu, 2004-01-22 at 00:27, Roland Scheidegger wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
--- r200_state.c21 Jan 2004 16:08:43 -1.9
+++ r200_state.c21 Jan 2004 22:30:21 -
@@ -1695,7 +1734,7 @@
case GL_COLOR_MATERIAL
Michel Dnzer wrote:
On Thu, 2004-01-22 at 00:16, Roland Scheidegger wrote:
samples/sphere: the texture on the sphere looks wrong, almost
reversed (seems to be the same problem as with isosurf, both use
GL_SPHERE_MAP - GL_SPHERE_MAP seems to work correctly in the gloss
demo though interestingly
Keith Whitwell wrote:
Index: r200_state.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_state.c,v
retrieving revision 1.6
diff -p -u -r1.6 r200_state.c
--- r200_state.c27 Dec 2003 22:06:39 -1.6
+++
Here's a small patch which makes color / blend logic ops work with
r200/radeon (untested on radeon). It's actually a copypaste job from
the mesa sources, mesa has the comment
/* This is needed to support 1.1's RGB logic ops AND
* 1.0's blending logicops.
*/
wherever it tries to figure
Ian Romanick wrote:
Roland Scheidegger wrote:
Here's a small patch which makes color / blend logic ops work with
r200/radeon (untested on radeon). It's actually a copypaste job from
the mesa sources, mesa has the comment
/* This is needed to support 1.1's RGB logic ops AND
* 1.0's
Just for fun, tried all mesa demos/tests etc. with a radeon 7200 sdr.
redbook/alpha3d: nothing is seen unless a is pressed (and then only for
a very short time, buffering problem? (same as with r200)
samples/fog: the red part seems to have the fog applied quite
differently than with software
Just for fun, tried all mesa demos/tests etc. with a radeon 7200 sdr.
redbook/alpha3d: nothing is seen unless a is pressed (and then only for
a very short time, buffering problem? (same as with r200)
samples/fog: the red part seems to have the fog applied quite
differently than with software
(since the original email never made it to the list, a new one - it's
not a resend though)
texrect is broken here (and I've no idea why it works for other people ;-)).
There are 2 problems in the driver which cause this:
First, if glGenTextures is called, there is no texture target yet. This
Sorry for the spam, but I forgot another thing:
in r200UploadRectSubImage, shouldn't r200AllocDmaRegion just call for a
1024 byte alignment (since the blit offset looks like it needs to be
1024 byte aligned)? That'll get rid of the failed assertion with texrect
when using 16bit textures - the
Dieter Nützel wrote:
Am Freitag, 16. Januar 2004 20:00 schrieb Roland Scheidegger:
ok, here's another attempt, which uses an external dxtn library (patch
against current Mesa cvs trunk).
And, again? - After texture merge.
since you've asked ;-)
fixes:
- the dlopen stuff will no longer be built
Felix Kühling wrote:
(resending due to SF mailing list problems ...)
Hi,
after a CVS upgrade last night I got two some assertions in the radeon
driver. One happened when exiting from glxgears in radeonDeleteTexture.
Commenting out the assert statement helped.
I got the other one in Torcs when
Dieter Nützel wrote:
Am Freitag, 16. Januar 2004 20:00 schrieb Roland Scheidegger:
ok, here's another attempt, which uses an external dxtn library (patch
against current Mesa cvs trunk).
And, again? - After texture merge.
since you've asked ;-)
fixes:
- the dlopen stuff will no longer be built
Michel Dnzer wrote:
Seems to work fine here (same as with software rendering) - try
disabling codegen maybe? Didn't you notice yuvrect being broken
though? :\
Well I've reported yuvrect as broken in the earlier email - no need to
repeat everything.
Right.
No idea why texrect doesn't work
Dieter Nützel wrote:
Am Samstag, 24. Januar 2004 03:00 schrieb Roland Scheidegger:
Dieter Nützel wrote:
Am Freitag, 16. Januar 2004 20:00 schrieb Roland Scheidegger:
ok, here's another attempt, which uses an external dxtn library (patch
against current Mesa cvs trunk).
And, again? - After
Keith Whitwell wrote:
Roland Scheidegger wrote:
(since the original email never made it to the list, a new one - it's
not a resend though)
texrect is broken here (and I've no idea why it works for other people
;-)).
There are 2 problems in the driver which cause this:
First, if glGenTextures
Keith Whitwell wrote:
Roland Scheidegger wrote:
Keith Whitwell wrote:
Unfortunately it's not. Mesa will initialize the correct
default wrap and filter mode when glBindTexture is called with
the rectangle_nv target and the texture object already exists
(that is, glGenTextures has been called
Hello all
here's a patch which fixes all remaining lighting problems (well those I
could see at a glance) with NWN on r200 (likely also fixes the same bugs
on radeon, untested). (I mentioned these problems earlier, the almost
black target indicator, the almost black (instead of blue) portals,
Hello again
now that the lighting bugs are finally mostly gone, I've just gone ahead
and changed the lighting code a bit more... (patch against cvs, without
the earlier colormat fix).
This patch causes the driver to no longer use the PREMULT lighting,
instead it will use the SOURCE_MATERIAL
Ronny V. Vindenes wrote:
On Sat, 2004-01-31 at 03:30, Roland Scheidegger wrote:
Hello again
now that the lighting bugs are finally mostly gone, I've just gone ahead
and changed the lighting code a bit more... (patch against cvs, without
the earlier colormat fix).
patching file r200_state.c
Dieter Nützel wrote:
Sorry Roland, NO go:
182 22:47 patch -p0 -E -N ~/Dokumente/DRI-Mesa/r200_colormatfix.diff
184 22:47 cd src/mesa/drivers/dri/radeon/
185 22:47 patch -p0 -E -N ~/Dokumente/DRI-Mesa/radeon_colormatfix.diff
186 22:47 cd -
187 22:47 cd
Michel Dnzer wrote:
I think it was applied a while ago (assuming we're thinking of the same
patch, try not to be so terse, the subject isn't the body...).
IIRC correctly this was just a cosmetic change which would have made it
possible to support 6 texture units in the emit_statelist path. But
Ronny V. Vindenes wrote:
OK, I've spent a few hours playing with the updated patch today, and
all I can say is: Good work! It fixes lighting and fog issues in many
cases (including one program that segfaults without it). Also, in
most the programs I've tested there are small performance
Michel Dnzer wrote:
On Sat, 2004-01-31 at 22:34, Roland Scheidegger wrote:
now that the lighting bugs are finally mostly gone, I've just
gone ahead and changed the lighting code a bit more... (patch
against cvs, without the earlier colormat fix).
Good work! This fixes neverball and neverputt
Keith Whitwell wrote:
Roland Scheidegger wrote:
Ronny V. Vindenes wrote:
OK, I've spent a few hours playing with the updated patch today, and
all I can say is: Good work! It fixes lighting and fog issues in many
cases (including one program that segfaults without it). Also, in
most the programs
Keith Whitwell wrote:
The rendering errors are a harder problem though, I can see now why
the material between begin/end fallback was needed in the first place.
There doesn't seem to be an easy way currently to submit material
changes between vertices, so it looks like the fallback needs to
Here are the cleaned-up texrect fixes - last time there was still some
disagreement about how some things should be fixed.
If there are no objections I'm just going to try out my newly aquired
super-powers and commit it ;-).
Roland
(btw sorry if this appears twice on the list. The mail list
Here are the cleaned-up texrect fixes - last time there was still some
disagreement about how some things should be fixed.
If there are no objections I'm just going to try out my newly aquired
super-powers and commit it ;-).
Roland
Index: src/mesa/drivers/dri/r200/r200_tex.c
Ian Romanick wrote:
Roland Scheidegger wrote:
Here are the cleaned-up texrect fixes - last time there was still some
disagreement about how some things should be fixed.
If there are no objections I'm just going to try out my newly aquired
super-powers and commit it ;-).
Nervous about your
If there are no objections, I'd like to commit the lighting changes
(early next week) for the r200. As far as I can see it doesn't cause any
regressions, even though according to my measurements it doesn't really
speed up things that much except when the two-side lighting fallback can
be
Now that I've commited the lighting changes for r200 (still has the
material fallback though), I've wanted to commit the same changes (well
not exactly the same of course ;-)) to the radeon driver too (some brief
testing showed it worked just fine). But I'm a bit confused, the code
I'll need
Dieter Nützel wrote:
Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive:
On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote:
[ Following up to the dri-devel mailing list, we aren't really
using the sf.net bug tracker anymore but rather the kernel and
XFree86 bugzillas ]
On Mon, 2004-02-09
Michel Dnzer wrote:
Works perfectly here... Do you have current DRI CVS from
freedesktop.org? If so, please post the errors.
Speaking of that, I've seen some users get dri cvs from sourceforge.net
accidentally. Couldn't someone commit a fix so when you try to build
it you just get some error
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently in
the tnl code? The crashes sometimes are predictable (for instance in
the old ut it'll always crash in the intro when the announcer says
in twenty-two ninety
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently
in the tnl code? The crashes sometimes are predictable (for
instance in the old ut it'll always crash in the intro
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently
in the tnl code? The crashes sometimes are predictable (for
instance
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very
recently in the tnl code
OK, perhaps you could check in the restored version for now. I may
not get to look into this further for a day or two.
-Brian
Oh - such a drastic measure :-(. Is there some way to revert changes in
cvs, or do I just have to submit that as a new version, maybe even with
tricks like update it
1 - 100 of 492 matches
Mail list logo
