Am 14.05.2005 21:17:07 schrieb(en) Ryan Richter:
I'm using Xfree 4.3 (Debian sid), so I don't think that will work. Is
this even applicable to this version of X?
If you are using bash:
export tcl_mode=0
glxinfo
will show that tcl is off: NO-TCL in the renderer string.
start your programm from
Am 11.05.2005 18:21:59 schrieb(en) Ryan Richter:
Another one today, but it's a little different now. I got to see this
happen from the beginning today. A few minutes before the crash, 3D
operations become very slow. When X hangs, it's now doing this:
when comparing radeon_tcl.c with
Am 23.01.2005 02:42:41 schrieb(en) Dave Airlie:
It's strange you get better results with OLD_PACKETS and MAOS_VERTS
set to 0.
I've tried that on my 7200sdr just very recently, and with that
quake3 locks
up usually within a few ms, sometimes it will live some seconds...
But with OLD_PACKETS and
Am 23.01.2005 12:23:18 schrieb(en) Dave Airlie:
Okay it was an old bug resurfaced by the looks of it.. there used to
be
code written by Felix in the radeon driver to always emit a zbs atom
no
matter what, I've spent two days staring at the driver and the
attached
patch looks to fix the gears
Am 23.01.2005 13:33:25 schrieb(en) Keith Whitwell:
Andreas Stenglein wrote:
[...]
The easiest way might be to just revert the changes from 25/26th
sept.
This should be acceptable since these changes introduced a show
stopper (IMHO).
OTOH it would be nice to find the real bug.
Unfortunately
9600/9700 chip.
I won't find time this weekend .. but hopefully in the next few weeks.
best regards,
Andreas Stenglein
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop
could someone try current radeon driver from mesa-cvs HEAD
to see if it works with gears/glxgears in tcl and non-tcl mode?
I was able to get instant reboots, deadlocks and hangs.
The driver before 25.Sep.2004 seems ok.
(you might switch off dma for all harddisks and do sync before trying...)
Am 2004.10.16 00:59:07 +0200 schrieb(en) Ian Romanick:
Andreas Stenglein wrote:
Could someone else with an R100 test?
see attached patch ( some changes to make mesa compile with gcc2.95.3 omitted)
What were those changes? Were they to avoid the SSE2 code?
1) basically some brackets
Am 2004.10.13 23:37:12 +0200 schrieb(en) Ian Romanick:
Michel Dänzer wrote:
Anyway, I think we're on a tangent here, as the problem doesn't seem to
be PPC specific at all.
I dug out the Rage 128 that I have for the PC, and it works just fine.
glxgears, readpix, all of it. :(
The PCI
Am 2004.10.13 23:37:12 +0200 schrieb(en) Ian Romanick:
Michel Dänzer wrote:
Anyway, I think we're on a tangent here, as the problem doesn't seem to
be PPC specific at all.
I dug out the Rage 128 that I have for the PC, and it works just fine.
glxgears, readpix, all of it. :(
The PCI
Am 2004.10.13 03:51:44 +0200 schrieb(en) Eric Anholt:
[...]
New patch at:
http://pdx.freedesktop.org/~anholt/dri/r200-projtex-8.diff
[...]
It seems Radeon R100 and R200 can't do projective texturing when
using tiny vertices (without w).
While fiddling around with R100 and tvertex-patch i
Am 2004.10.12 03:37:05 +0200 schrieb(en) Ian Romanick:
I was trying to test the latest version of my ReadPixels work to make
sure I didn't break anything on big-endian. However, it seems someone
beat me to it in the Rage128 driver. :) In a nutshell, I can get one
frame of gears, and then
Am 2004.10.12 18:38:18 +0200 schrieb(en) Ian Romanick:
Andreas Stenglein wrote:
It might be unrelated (and just some other silly mistake/problem):
Using my local version of radeon (r100) driver converted to t_vertex
I discovered a similar problem recently.
1) running glxgears I get
Am 2004.10.12 18:38:18 +0200 schrieb(en) Ian Romanick:
Andreas Stenglein wrote:
It might be unrelated (and just some other silly mistake/problem):
Using my local version of radeon (r100) driver converted to t_vertex
I discovered a similar problem recently.
1) running glxgears I get
-coords.
greetings,
Andreas
Am 2004.10.10 19:13:51 +0200 schrieb(en) Andreas Stenglein:
Am 2004.10.10 11:14:11 +0200 schrieb(en) Eric Anholt:
http://pdx.freedesktop.org/~anholt/dri/r200-projtex-6.diff
#4 had broken nontcl quite significantly. I'm thinking I just stomped
some of my changes
Am 2004.08.14 01:02:13 +0200 schrieb(en) Brian Paul:
[...]
Well, I could probably make the Mesa 6.1 release this weekend (since I
was planning on working anyway). I've got some memory leak fixes (see
bug 1002030) that I haven't checked into the trunk yet (but are
checked into the
Am 2004.08.10 07:23:57 +0200 schrieb(en) Kevin E Martin:
On today's release wranglers call, someone asked if there were any new
fixes from the DRI or Mesa projects that should be included in the next
X.Org release. If there are any, could you please let us know? Thanks!
1)
bug #988:
fixes build of sis driver with current mesa sources
Index: xc/xc/lib/GL/mesa/drivers/dri/sis/Imakefile.inc
===
RCS file: /cvs/dri/xc/xc/lib/GL/mesa/drivers/dri/sis/Imakefile.inc,v
retrieving revision 1.4
diff -u -r1.4 Imakefile.inc
here is a new snapshot for R100 based cards
(only for testing, isn't ready for merging)
It seems to work ok with most apps I tested,
but it doesn't work for yuvrect.
Do we need the _radeon_render_stage or
should the _tnl_render_stage be enough?
best regards,
AndreasIndex:
The result of _tnl_CreateContext( ctx ) isn't checked anywhere.
and so you may get a sigsegv later in _tnl_install_attrs()
in this line:
vtx-emit = choose_emit_func;
because ctx-swtnl_context is NULL if CALLOC didnt work.
This occurs with some demos when trying to run them in wine (CVS),
for
Am 2004.04.21 00:26:41 +0200 schrieb(en) Brian Paul:
[...]
Do you mean glXCreateContext()? Are the function parameters the same
for both calls?
yes its called twice, no with different parameters.
I tried to see what happens with the Mesa-Software-Renderer libGL with DEBUG on
and it doesnt
Am 2004.04.19 00:51:16 +0200 schrieb(en) Michel Dänzer:
On Mon, 2004-04-19 at 00:29, Andreas Stenglein wrote:
After setting tcl_mode to 0, glxgears and quake3 didnt work as expected.
glxgears looks like http://penguinppc.org/~daenzer/DRI/glxgears.png
here; if I press the cursor keys
Am 2004.04.19 20:09:29 +0200 schrieb(en) Keith Whitwell:
Andreas Stenglein wrote:
[...]
it's almost the same here on x86: only the colors look a bit different.
red corners, blue ring, black middle
If you change the shape of the glxgears-window to widescreen
you will see something rotating
I tried to merge the r200 patch to the radeon driver.
Here is a snapshot.
(hopefully I didn't miss something while sorting out the r200 stuff from the diff.)
I tested:
glxgears works, quake3 works, ut2004demo works (at least to a certain extend)
progs/tests/projtex doesn't work as it should,
sorry..
I missed to set tcl_mode=0,
so the programs were running in HW-TCL mode.
After setting tcl_mode to 0, glxgears and quake3 didnt work as expected.
best regards,
Andreas
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free
here is patch against Mesa CVS HEAD to refactor i830 texcombine
as its done in radeon/r200 driver.
it compiles, but its untested if it works.
feel free to test, modify, commit, drop
best regards,
Andreas Stenglein
Index: Mesa/src/mesa/drivers/dri/i830/i830_texstate.c
Am 2004.03.06 14:59:14 +0100 schrieb(en) Jaakko Niemi:
On Sat, 03 Jan 2004, Andreas Stenglein wrote:
here is what I fiddled together to support the 3rd TMU on radeon
and 6TMUs on r200.
I tried on R200 with multiarb.c and projtex.c and it works almost as it should.
(projtex is broken
Am 2004.02.14 00:11:35 +0100 schrieb(en) Roland Scheidegger:
Andreas Stenglein wrote:
Just tried ut2003 on R100 with current DRI+MESA cvs HEAD.
Now with the MULT-code in radeon_state.c radeon_state_init.c
(change lighting to use MULT instead of PREMULT ...) the
shading/lighting
Just tried ut2003 on R100 with current DRI+MESA cvs HEAD.
Now with the MULT-code in radeon_state.c radeon_state_init.c
(change lighting to use MULT instead of PREMULT ...)
the shading/lighting of warriors changed a little bit in tcl-mode.
It's been buggy before in tcl-mode, but differently.
Now
just tried to run ut2003_demo with radeon_dri.so from current
DRI-cvs/MESA-cvs HEAD and got a SIGSEGV, just before the logo
usually is displayed.
However ut2003_demo worked well with an older radeon_dri.so
from xfree-cvs (20031226) I had lying around and it worked
with radeon_dri.so from DRI-CVS
like the R200 one.
It doesnt contain intendation fixup yet.
I tried only with q3a.
best regards,
Andreas
mesa_radeon_texcombine_refactor.diff
Description: Binary data
Am 2004.02.07 09:44:39 +0100 schrieb(en) Ian Romanick:
[...]
as well. I'll try to have a patch tomorrow. The server-side of things
Looks like its fixed in DRI CVS with/since your patch.
I have to admit that I only tried with the new libGL.so and old
Xserver/libs, not with old libGL and new
Am 2004.02.04 21:00:14 +0100 schrieb(en) Brian Paul:
Ian Romanick wrote:
[snip]
Making that change and changing the server-side to not advertise a core
version that it can't take protocol for would fix the bug for 4.4.0. Do
you think anything should be done to preserve text after the
after setting LIBGL_ALWAYS_INDIRECT=1
glxinfo shows
OpenGL version string: 1.5 Mesa 6.0
but doesnt show all extensions necessary for OpenGL 1.5
An application only checking for GL_VERSION 1.5 would probably fail.
Any idea what would happen with libGL.so / libGLcore.a from different versions
of
just discoverd that at least anonymous cvs acces to mesa and dri
cvs repository doesnt work:
cvs -z9 -d:pserver:[EMAIL PROTECTED]:/cvs/dri update -dA xc
cvs update: Updating xc
cvs update: failed to create lock directory for `/cvs/dri/xc' (/cvs/dri/xc/#cvs.lock):
Permission denied
cvs update:
it looks like its in the 2.4.25pre Kernel now,
whats about XFree CVS?
best regards,
Andreas
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity.
Am 2004.01.14 00:43:07 +0100 schrieb(en) Roland Scheidegger:
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
Does the R100 hardware support cubemapping with mipmaps
and/or hw-tcl?
greetings,
Andreas
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching
will the savage driver work with savage4 pci cards?
greetings,
Andreas
Am 2004.01.09 22:47:40 +0100 schrieb(en) Alex Deucher:
just an FYI, I switched the code in savage_dri.c to use the global
bitmap descripter for the front buffer, the primary BD for the back
buffer and the secondary BD for
after setting a breakpoint in radeonFlushCmdBuf and
then single stepping I noticed that while beeing
between LOCK_HARDWARE() and UNLOCK_HARDWARE()
the Xserver freezes but cursor movement still occured.
Is this A) allowed or should
B) nothing touch the hardware at this time?
greetings,
Andreas
Am 2004.01.03 16:22:54 +0100 schrieb(en) Felix Kühling:
[...]
I just added a short HOWTO to the Wiki:
http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationForDevelopers.
Let me know if you find any problems with the config code or the HOWTO.
thanks a lot!
I'm going to try your patch
just discovered...
here: http://www.siliconmotion.com/en/sm731.htm
on the left side of the page.
2MByte pdf
its a ultra low power device for use in tablet-PCs.
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in
Am 2003.12.29 21:23:45 +0100 schrieb(en) Daniel Vogel:
[...]
I believe exposing the GL_EXT_texture_compression_s3tc and
GL_ARB_texture_compression extensions implies the driver to handle S3TC
compression as an application can pass in uncompressed data, ask the driver
to compress it and then
trivial fix for another GL_RENDERER string issue.
(introduced while removing radeon_compat mode.)
Needed in XFree86 CVS HEAD, too.
before:
OpenGL renderer string: Mesa DRI Radeon 20030328 AGP 2x x86/MMX+/3DNow!+/SSETCL
^^
it looks like the file
Mesa-newtree/src/mesa/drivers/dri/radeon/radeon_lighting.c
isnt needed anymore.
At least it isnt in the Makefile.
Andreas
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just
Am 2003.11.28 16:15:55 +0100 schrieb(en) Michel Dänzer:
On Fri, 2003-11-28 at 13:00, Andreas Stenglein wrote:
I found another program using scissors that triggers
(maybe) the same bug: lesson24 from nehe.gamedev.net
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=24
(glut
hello
unfortunately your mail got lost somehow.
In the meantime I searched bugs.xfree86.org and found bugs #787
and #788 which I think are related to this problem.
I added some info to bug #788.
Later I noticed that his problem was on *BSD, not on Linux.
Maybe you could have a look at it.
Am 2003.11.28 16:15:55 +0100 schrieb(en) Michel Dänzer:
On Fri, 2003-11-28 at 13:00, Andreas Stenglein wrote:
I found another program using scissors that triggers
(maybe) the same bug: lesson24 from nehe.gamedev.net
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=24
(glut
Am 2003.11.19 23:15:15 +0100 schrieb(en) Michel Dänzer:
'That' annoying hang? Have I missed something? *shrug*
maybe..
You will get something similar when running ut2003_demo in non-tcl mode, too.
(on radeon7500 and on r200/radeon8500)
[...]
isnt it strange that RADEONWaitForIdleCP somehow
Hello!
yesterday I got that annoying xserver hang on R200.
XFree86 4.3.99.xx from october, DRI CVS HEAD (a few days old), Kernel 2.4.22 with v4l2.
I verified with a fresh build of XFree86 CVS HEAD (yesterday).
The strange things are the backtraces:
1. older XFree and current DRI CVS:
(gdb) back
Am 2003.11.15 20:46:01 +0100 schrieb(en) Peter Meffer:
after a long odyssey getting xfree86 dri to work (seemingly), everything
behaves as expected, except that the gl window (also fullscreen) remains
black; fps is being reported as usual (4300), no error messages appear,
neither in the
If environment no_rast=true is set, you will get a
segmentation fault when trying to destroy a context.
driver: r200, DRI CVS HEAD
maybe in radeon, too ...
Where should the destroyContext get stopped if
this option is used? in r200DestroyContext() or later?
greetings,
Andreas
backtrace:
Am 2003.10.06 14:45:39 +0200 schrieb(en) Michel Dänzer:
On Mon, 2003-10-06 at 14:06, Helge Hafting wrote:
Unfortunately, xserver-xfree86-dri-trunk from
http://people.debian.org/~daenzer/dri-trunk-sid/
hangs my machine rather quickly.
X comes up, and can be used in any way for a few
Am 2003.08.20 01:02:59 +0200 schrieb(en) Michel Dänzer:
...
btw: Is hardware-accelerated OpenGL on a Radeon 9000 PCI possible on FreeBSD?
I don't know if PCI GART works on the BSDs yet, but while we're at it,
what's the subsystem ID of the card? :)
I dont have such a card.
Its been a
Am 2003.08.19 22:20:58 +0200 schrieb(en) Michel Dänzer:
So here it is at last. :)
http://penguinppc.org/~daenzer/DRI/radeon-pci-roundup.diff
It ended up quite a bit larger than I initially thought it would, but
most of it is straightforward (and some less straightforward, like a DDX
trivial...
fixes some typos in the radeon driverdiff -ru HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c HEAD/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c
--- HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c Wed Apr 30 03:50:52 2003
+++
Am 2003.08.05 22:45:36 +0200 schrieb(en) Ian Romanick:
Keith Whitwell wrote:
I'm happy to drop these once we have identified implemented a suitable
replacement.
There are two ways to go on this. One way is to make a new
GLX_MESA_memory_allocate extension that just extends the
Am 2003.08.04 20:58:57 +0200 schrieb(en) Ian Romanick:
Andreas Stenglein wrote:
Is someone working on a solution for the non-tcl path already?
Or isnt that necessary for that path? (t_dd_dmatmp.h)
Yes. The same types of changes Keith made to t_dd_dmatmp2.h need to be
made
Am 2003.07.25 18:44:20 +0200 schrieb(en) Doug Rabson:
Oh, I meant to say also that if anyone is interested in tracking down
and fixing the r200 rendering problems, I can supply full buildable
source code to the low-level OpenGL parts of the engine.
nice, Im wondering nobody replied.
maybe
Am 2003.07.29 22:41:30 +0200 schrieb(en) Ian Romanick:
...
2. I don't like the hackish handing of the pre-1.3 DRM case. Are there
other PCI IDs that need the 128MB offset? Do we even support the
pre-1.3 DRM anymore? If we don't support the pre-1.3 DRM (and don't
intend to fix the
Am 2003.07.06 06:03:54 +0200 schrieb(en) Ian Romanick:
Andreas Stenglein wrote:
how to enable Mesa Verbose Debugging in the DRI-tree?
http://mesa3d.org/debugging.html didnt help much
It depends on the driver. Most of the drivers have an environment
variable that's *_DEBUG (i.e
how to enable Mesa Verbose Debugging in the DRI-tree?
http://mesa3d.org/debugging.html didnt help much
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Ian,
thanks a lot for having a look at it.
Am 2003.06.27 03:19:00 +0200 schrieb(en) Ian Romanick:
Andreas Stenglein wrote:
here is a patch that works at least for multiarb.c
It is against HEAD from 19 June 2003
(I cleaned it up a bit but its not ready for merge:
still some questions
here is a patch that works at least for multiarb.c
It is against HEAD from 19 June 2003
(I cleaned it up a bit but its not ready for merge:
still some questions...)
1) could someone with an 8MB or 16MB Radeon check if the
resulting max_texturesize is big enough?
(just use mesa's glxinfo: glxinfo
Am 2003.06.10 12:18:23 +0200 schrieb(en) Dave Jones:
I have the specs for this monster, but it's a bit funky.
Do you have full enough specs to can say that it should work
with the radeon driver if agpgart is available, or to can say
what needs to be done on the radeon driver?
Do you have specs
thanks a lot!
btw, I got the 3rd TMU working with hw-tcl and codegen, too.
(at least multiarb.c works)
I'm going to clean the patch up a bit, so that it only contains
things related to 3rd TMU support.
Am 2003.06.23 12:17:26 +0200 schrieb(en) Michel Dänzer:
On Sat, 2003-06-21 at 14:14, Andreas
Am 2003.06.23 19:12:01 +0200 schrieb(en) Keith Whitwell:
Ian Romanick wrote:
Andreas Stenglein wrote:
I tried to get the 3rd TMU working on radeon,
and with this patch it works at least
without hw-TCL for multiarb.c from Mesa/demos.
(RADEON_TCL_FORCE_DISABLE=1)
With hw-TCL
Am 2003.06.21 22:23:40 +0200 schrieb(en) Daniel Vogel:
On Sat, Jun 21, 2003 at 02:14:20PM +0200, Andreas Stenglein wrote:
Which programs/demos/games could/should be tested as
they make use of the 3rd texture unit?
There was a patch on the list ages ago (before a lot of
the new
Now I have it working with hw-tcl, too. :)
(Just missed a few bits here and there)
But its necessary to disable codegen or vtxfmt.
(export RADEON_NO_CODEGEN=1)
greetings,
Andreas
---
This SF.Net email is sponsored by: INetU
Attention Web
I tried to get the 3rd TMU working on radeon,
and with this patch it works at least
without hw-TCL for multiarb.c from Mesa/demos.
(RADEON_TCL_FORCE_DISABLE=1)
With hw-TCL the 3rd texture is visible, but
isnt rotating.
The patch also includes some code for the
kernelmodule for cube-textures on
Am 2003.06.19 20:42:44 +0200 schrieb(en) Keith Whitwell:
[...]
Log message:
Prepare to enable texunits 3 4
[...]
nice to see that (as it could also help the radeon/r200 driver ;))
btw, you might need to change some files from mesa, too.
It was necessary to patch
in radeon_context.h RADEON_OLD_PACKETS is defined to 1
It was defined to 0 during the tcl-0-0-branch work/merge,
but was reverted back to 1 about 3 weeks later due to problems.
CVS log for dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.h
[...]
Revision 1.13
[...]
Changes since 1.12: +1 -1
while trying to activate the 3rd TMU on radeon
I discovered that txr states get emitted even
in the yuvsqare (and multiarb) demo
(which use only standard textures):
(RADEON_DEBUG=state and yuvsqare demo:)
radeonBindTexture( 0x8132dc8 ) unit=0
radeonEmitState
radeonEmitState - lost context
Am 2003.06.13 17:00:20 +0200 schrieb(en) Keith Whitwell:
Andreas Stenglein wrote:
[...]
btw. heres also a patch for mplayer vo_gl.c which uses
GL_NV_texture_rectangle.
I sent a (sligtly) older version to mplayer-dev-eng, but
unfortunately it
got caught by some filter/ wasnt released
Am 2003.06.10 12:12:56 +0200 schrieb(en) Keith Whitwell:
Keith Whitwell wrote:
Andreas Stenglein wrote:
@keithw: here is another version.
yuvrect.c seems to work
texrect.c still doesnt work
any hints?
OK, the final piece of the puzzle fell into place. Without the
radeon docs you might hav had
Am 2003.06.10 13:14:28 +0200 schrieb(en) Keith Whitwell:
[...]
I was thinking that this would be a fairly easy option:
a) Disable TCL for all rectangular texture operations
b) Insert a new stage to the swtcl pipeline, based on
Mesa/src/tnl/t_vb_texmat.c, to perform a 1/w, 1/h scale to all
What would be the best case scenario?
assumptions follow...
- IGP is just a northbridge with integrated radeon core.
Some limitations could be there:
1. low local memory, just for the framebuffer
1a) maybe you have to grab some more local memory for
higher resolutions (like i810?)
(look into
Am 2003.06.09 23:19:16 +0200 schrieb(en) Keith Whitwell:
[...]
I've been playing a bit more -- it's kind of odd what works
doesn't... I haven't really got a handle on it yet...
Keith
I modified yuvrect so that it uploads an rgb-image, (rgbrect)
result (as expected): doesnt work.
btw: its
@keithw: here is another version.
yuvrect.c seems to work
texrect.c still doesnt work
any hints?
greetings,
Andreas
Only in mod_trunk: build
Only in trunk_orig: cvs-logdatei
Only in trunk_orig: update_cvs
diff -ru trunk_orig/xc/xc/extras/Mesa/src/enums.c mod_trunk/xc/xc/extras/Mesa/src/enums.c
different
on radeon?
best regards,
Andreas
Am 2003.05.30 00:56:42 +0200 schrieb(en) Andreas Stenglein:
I copied together (from r200 driver)
a patch which enables GL_NV_texture_rectangle
on radeon.
The yuvrect.c test from mesa seems to work,
but texrect.c doesnt. strange.
Other issues:
1
I copied together (from r200 driver)
a patch which enables GL_NV_texture_rectangle
on radeon.
The yuvrect.c test from mesa seems to work,
but texrect.c doesnt. strange.
Other issues:
1) radeonEmitBlit uses an already shifted
color_fmt, which is defined in radeon_reg.h,
r200EmitBlit uses an
It works (as expected).
to a) For ..._FPALPHA its then as in the r200-driver.
to b) Who know's what should be done if lighting is
enabled but (ctx-Light.ColorMaterialEnabled) isnt set?
At least your patch which enables .._PKCOLOR
didnt affect the programs I tried.
Later I tried to enable
Am 2003.03.30 17:45:23 +0200 schrieb(en) Brian Paul:
Andreas Stenglein wrote:
So in VTXFMT Mode, RADEON_CP_VC_FRMT_FPALPHA isnt added to ind,
and so some programs dont look as good as they do when
NO_VTXFMT=1 is set.
ctx-Color.AlphaEnabled refers to GL_ALPHA_TEST. It has nothing to
do whatsoever
Hello,
it looks as ctx-Color.AlphaEnabled isn't set,
at least not in glMaterialfv() (or at all?).
So in VTXFMT Mode, RADEON_CP_VC_FRMT_FPALPHA isnt added to ind,
and so some programs dont look as good as they do when
NO_VTXFMT=1 is set.
(exaple: arkhart-demo http://arkhart.nekeme.net/en/ or
Am 2003.03.25 10:58:15 +0100 schrieb(en) Keith Whitwell:
Andreas,
Does this work for you?
Yes, at least the part with GL_TRIANGLE_STRIP.
In case of 0 you can just return 0, no copying is needed.
case 0: return 0; break;
Keith
--- radeon_vtxfmt.c 4 Mar 2003 01:02:33 - 1.10
+++
Am 2003.03.25 21:02:24 +0100 schrieb(en) Keith Whitwell:
Gareth Hughes wrote:
Andreas Stenglein wrote:
Yes, at least the part with GL_TRIANGLE_STRIP.
In case of 0 you can just return 0, no copying is needed.
case 0: return 0; break;
You're going to do that, just in a slightly different manner
:
Andreas Stenglein wrote:
this patch helps for the demo.
but someone more familiar with radeon_vtxfmt should
check if it really fixes all cases...
I think in case of GL_QUAD_STRIP we should check
for 0, too.
(and maybe for 1?)
--- radeon_vtxfmt.c_origFri Mar 21 17:22:23 2003
+++ radeon_vtxfmt.c
Hello,
just discovered that the fallback in radeon_Materialfv()
in radeon_vtxfmt.c seems to do not work.
I disabled the fallback by just printing the function
glMaterialfv() to stderr
(so I know I'm now running the modified radeon_dri.so)
and the result is the same as before, not better, not
Hello,
It looks like there is different behavior if
you are using builtin radeon (and agpgart) instead
of using modules radeon.o and agpgart.o:
If I start X from command-line, exit session,
startx again, X and DRI seems to work fine, at least
there is no lockup. (radeon and agpgart as modul)
As I
Am 2003.03.06 23:03:56 +0100 schrieb(en) Ian Romanick:
It should. If it doesn't, then it's a bug and I'd like to hear
about it. :)
Hello,
thanks for the info!
Yes, it does work (at least with most applications I tried)
But I was able to get the
Xserver hang but mousepointer moving,
when running
Hello!
The radeon.o kernelmodule from the drm-filp-0-1-branch works well.
xmms with different opengl-based visual-plugins works, even with
vtxfmt enabled.
I activated, deactivated the plugins often and nothing bad happend:
no -22 and no bad entrys in /var/log/messages.
I got a segfault from xmms
Am 2003.03.02 19:34:35 +0100 schrieb(en) Linus Torvalds:
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
Hello!
yes, this patch helps quake3 in sw-tcl mode (no more flickering of
textures).
It looks even better than hw-tcl, because hw-tcl
shows that other flickering when looking to the
ground and turning around a bit.
But unfortunately it doesnt solve the issue with
the invisible player-model in
export RADEON_NO_VTXFMT=1 helped me.. but its just a workaround
Am 2003.02.03 12:00:49 +0100 schrieb(en) Charl P. Botha:
On Mon, 2003-02-03 at 11:50, Adam K Kirchhoff wrote:
Do we know the causes of these error messages:
drmCommandWrite: -22
drmRadeonCmdBuffer: -22 (exiting)
I don't get
Hello!
anytime I try to update my local copy of DRI from cvs I get a
connection refused.
On the sourceforge website I found nothing about it.
Did they change something or are they (sourceforge) working to fix
the problem?
best regards,
Andreas
thanks a lot!
Am 2003.01.16 23:31:23 +0100 schrieb(en) Eric Anholt:
SF Site status:
http://sourceforge.net/docman/display_doc.php?docid=2352group_id=1
---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your
What happend to the mesa3d website?
www.mesa3d.org doesnt work as expected since a few days:
It only shows a text mesa3d.org is a parked domain
regards,
Andreas
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
Am 2002.12.10 11:59:13 +0100 schrieb(en) Felix Kühling:
On Tue, 10 Dec 2002 10:37:07 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Charl P. Botha wrote:
Okay, I just checked and I can still reproduce a SIGFPE with
today's CVS.
I've made doubly sure that the new libGL is used. Here
Hello!
maybe someone should put this issue on the DRI-drivers
status table to prevent other people to fall into
this trap.
for example:
AGPGART devices/chipsets:
Depends on your Kernel/agpgart modul, most common
chipsets should work.
Linux users look into agpgart_be.c in your kernelsource.
Hello!
just tried it out with current trunk (where you just
committed this patch), but unfortunately it didnt help.
just got a xserver freeze, and after a restarting
of the xserver I tried it and got another error:
application died with segfault or with drmRadeonCmdBuffer: -22
Xlib: unexpected
1 - 100 of 115 matches
Mail list logo
