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.
Thanks,
Dieter
---
The SF.Net
On Wed, 21 Jan 2004 02:02:58 +0100
Andreas Happe [EMAIL PROTECTED] wrote:
On 2004-01-17, Micha Feigin [EMAIL PROTECTED] wrote:
If I got things right then the dri tree is not a complete X tree. You
need a working X installation to install over. It installs only the
modified files.
I've
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
On Wed, Jan 21, 2004 at 03:24:23PM +0100, Michel Dänzer wrote:
Well, yes, it's hard to package future changes. :)
(BTW, the XFree86 tag is only relevant in XFree86 CVS, and Ville's fixes
likely happened after 2003/10/05.)
Oops, you're right. They were from November.
PS: You get the
Keep in mind that if you have previously checked out a branch, the
'no -r' option will keep you on that branch. If you have previously
checked out a branch into your working area, make sure you do a
update with '-A' which forgets the sticky tags (in this case a branch).
Regards,
Matthew
Dave Airlie wrote:
Hi all,
I've just implemented output for ffmpeg to opengl using
rectangular ycbcr textures, and the speed is quite good (compared to
non-ycbcr mipmapped textures :-), but now I've
noticed of course I can't use it on the NVIDIA (*evil*) closed source
drivers... (a couple
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=1092
--- Additional Comments From [EMAIL PROTECTED] 2004-01-21 11:43 ---
I think Ian
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=1091
--- Additional Comments From [EMAIL PROTECTED] 2004-01-21 11:42 ---
I think Ian
On Wed, 2004-01-21 at 15:29, Roland Scheidegger wrote:
I'll assume this is also caused by these changes:
(in XFree log):
Symbol _mesa_init_driver_functions from module
/usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved!
DRI still works, but the use of LIBGL_ALWAYS_INDIRECT causes
On Mer, 2004-01-21 at 00:28, Adrian Bunk wrote:
Fix system.h to always define cmpxchg.h and check its presence at
runtime when the DRM module loads, then you can build 386 kernels that
support DRI on higher machines.
The problem isnt that cmpxchg definitely doesn't exist, so system.h is
--- Dave Airlie [EMAIL PROTECTED] wrote:
Hi all,
I've just implemented output for ffmpeg to opengl using
rectangular ycbcr textures, and the speed is quite good (compared to
non-ycbcr mipmapped textures :-), but now I've
noticed of course I can't use it on the NVIDIA (*evil*) closed
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
Is anyone here on the ARB so they can go bug for these specs to be
made part of the OpenGL core? With OpenML etc. popping up now, and
the advent of DVD players with 3D hardware in them (NUON, Playstation 2,
X-Box, Panasonic Q Gamecube, Sony PSX) it seems the time to stop
running around making 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
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 when to call the update
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
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).
It's also
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=1092
--- Additional Comments From [EMAIL PROTECTED] 2004-01-21 17:33 ---
I realize that,
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:
r200ColorMaterial(
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).
On Thu, 2004-01-22 at 01:38, Roland Scheidegger wrote:
Michel Dnzer wrote:
you did remove only the test, not the r200UpdateMaterial() call as well,
right? :)
Right, I even rechecked it...
However, you're suggestion is interesting, removing the
r200UpdateMaterial() call there works too
On Thu, 2004-01-22 at 02:01, Roland Scheidegger wrote:
Michel Dnzer wrote:
On Thu, 2004-01-22 at 00:16, Roland Scheidegger wrote:
tests/texrect: the girl texture is completely messed up, the other
looks a bit better.
Seems to work fine here (same as with software rendering) - try
24 matches
Mail list logo
