On Sat, 25 May 2002, Leif Delgass wrote:
On Sat, 25 May 2002, José Fonseca wrote:
On 2002.05.25 20:36 Frank C. Earl wrote:
On Saturday 25 May 2002 11:48 am, José Fonseca wrote:
So if you can't secure it in the end, your extra effort will be in
vain.
I just thought
Does anyone have any ideas on this? I haven't seen compiler messages like
this before when compiling the drm.
--
Leif Delgass
http://www.retinalburn.net
-- Forwarded message --
Date: Sun, 26 May 2002 00:37:11 +0200
From: Gerard Delafond [EMAIL PROTECTED]
To: Leif Delgass
...
A server error on shutdown is normal. We haven't fixed the signal 11 on
closing the screen yet. Is this happening on shutdown, or is the X server
crashing here on startup?
--
Leif Delgass
http://www.retinalburn.net
___
Don't miss
On Fri, 24 May 2002, Frank C. Earl wrote:
On Thursday 23 May 2002 04:37 pm, Leif Delgass wrote:
I've committed code to read BM_GUI_TABLE to reclaim processed buffers and
disabled frame and buffer aging with the pattern registers. I've disabled
saving/restoring the pattern registers
On Sat, 25 May 2002, Leif Delgass wrote:
On 24 May 2002, Al Tobey wrote:
As for the 3DLabs stuff, I think somebody (maybe me?) should really get
that stuff into shape. It might be a good feather in our cap when
Creative/3DLabs thinks about releasing their new chip this fall
Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
and throttling, without
using a pattern register.
--
Leif Delgass
http://www.retinalburn.net
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
On Sat, 18 May 2002, Felix Kühling wrote:
On Sat, 18 May 2002 11:30:28 -0400 (EDT)
Leif Delgass [EMAIL PROTECTED] wrote:
Did you have a 2D accelerated server running on another vt? The DDX saves
and restores its register state on mode switches, so it could be a problem
with the FIFO
at Monday's meeting, but
I'll be away for a couple of days and I wanted to get this checked in and
post a quick message for now...
--
Leif Delgass
http://www.retinalburn.net
___
Hundreds of nodes, one monster rendering program.
Now that's
://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED
to committing this now. I got gui-master blits working,
and pseudo-DMA is stable. Actually, the pseudo-DMA is probably faster
without blits, but I'm hoping that it will help with DMA. The DMA is
still prone to lock-ups, but most of the time it's recoverable.
--
Leif Delgass
http
On Mon, 13 May 2002, Ian Romanick wrote:
On Sun, May 12, 2002 at 06:18:58PM -0400, Leif Delgass wrote:
In working on AGP texturing for mach64, I'm starting from the Rage128
code, which seems to have some problems (though the texture aging problem
could affect other drivers). My
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
the 'if' block where we know there is no memBlock. Again this
situation can only occur if there is an AGP heap. Is there a reason for
this behavior in the Rage128 code that I'm missing, or is this a bug?
--
Leif Delgass
http://www.retinalburn.net
On Sun, 12 May 2002, José Fonseca wrote:
Leif,
On 2002.05.12 19:15 Leif Delgass wrote:
Jose,
I've been experimenting with this too, and was able to get things going
with state being emitted either from the client or the drm, though I'm
still having lockups and things are generally
as an three year old :-) .
Regards
Peter
--
Leif Delgass
http://www.retinalburn.net
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL
--
Leif Delgass
http://www.retinalburn.net
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED
(ATI_DRI_XAA_LINES) isn't referred to
anywhere else.
--
Leif Delgass
http://www.retinalburn.net
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED
/ \___/ \___/at the same time!
--
Leif Delgass
http://www.retinalburn.net
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED
is
after the kernel cleanup and ATIDRICloseScreen (atidri.c). I've haven't
figured out what function the callback points to yet. Does anyone know
where to look for this?
--
Leif Delgass
http://www.retinalburn.net
___
Have big
) 0 )
to
if ( mach64_do_wait_for_idle( dev_priv ) 0 )
and set MACH64_USE_DMA to 0.
As far as DMA goes however, that was working before (just slowly), right?
So we do have a regression there.
--
Leif Delgass
http://www.retinalburn.net
them.
Now, it's time for sleep...
--
Leif Delgass
http://www.retinalburn.net
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED
this before?
Yeah, the first thing is to determine if it's really possible to kick off
a second DMA pass from within a DMA buffer.
--
Leif Delgass
http://www.retinalburn.net
___
Have big pipes? SourceForge.net is looking for download
...
Actually, at the moment 2D accel is disabled at compile time. This is
easy to fix though, we can just check pATI-directRenderingEnabled,
because it's already determined by the time we get to ATIMach64AccelInit.
--
Leif Delgass
http://www.retinalburn.net
if you experience a lockup again. There will be some
big changes coming in the drm in 0-0-4 soon, so it's likely to be a bit
unstable for a while.
--
Leif Delgass
http://www.retinalburn.net
___
Have big pipes? SourceForge.net
. On the security
issue, I think we need to be careful about how we handle blits. Frank's
code for _dma_buffers allows sending buffers to the DRM, does that mean
this takes the place of _dma_vertex? I assume you still need to call this
to allocate the buffers before filling them.
--
Leif Delgass
http
if we'll need private buffer data if we're using interrupts
rather than buffer aging. I suppose the primitive type would be needed if
we move the command placement in vertex buffers to the drm. Does anyone
know why the template code omits private structures for PCI DMA buffers?
--
Leif Delgass
http
.
--
Leif Delgass
http://www.retinalburn.net
? ppc.diff
Index: mach64_drv.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Attic/mach64_drv.h,v
retrieving revision 1.1.6.3.2.11
diff -u
On Wed, 1 May 2002, Leif Delgass wrote:
Try the attached patch. It's merged with the current changes so it should
apply. I checked in some changes after Jose made his original patch.
Oops, I had an errant semicolon there. Try this one. Patch with:
patch -p0 -i mach64-endian-mmio-3.diff
contexts are running.
Cheers,
Sergey
--
Leif Delgass
http://www.retinalburn.net
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED
(MMIO). Is MACH64_USE_DMA set to 0 or 1? Is this
with the MMIO patch applied?
--
Leif Delgass
http://www.retinalburn.net
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get
at it. If it
looks ok as a starting point, I can check it in.
--
Leif Delgass
http://www.retinalburn.net
mach64-dma-merge.diff.gz
Description: GNU Zip compressed data
to get
results ASAP), but I can put the DMA by default so that the interested
ones can try. In the worst case, they can always use the
mach64-0-0-3-branch.
I'll work on this, it should be fairly simple to do.
--
Leif Delgass
http://www.retinalburn.net
-endian, whereas the register
address has to be swapped from little-endian back to big-endian for the
MMSELECT(reg). So wouldn't you have to swap the value back to big-endian
as well in order to use this modified MACH64_WRITE macro?
--
Leif Delgass
http://www.retinalburn.net
for download mirrors. We supply
the hardware. You get the recognition. Email Us:
[EMAIL PROTECTED]
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
On 1 May 2002, Michel Dänzer wrote:
On Tue, 2002-04-30 at 23:53, Leif Delgass wrote:
On Tue, 30 Apr 2002, José Fonseca wrote:
On 2002.04.30 22:07 José Fonseca wrote:
... Next in mach64_drv.h, let's try the following definitions for the
MMIO:
#define MACH64_READ(reg
On Tue, 30 Apr 2002, Leif Delgass wrote:
On 1 May 2002, Michel Dänzer wrote:
On Tue, 2002-04-30 at 23:53, Leif Delgass wrote:
On Tue, 30 Apr 2002, José Fonseca wrote:
On 2002.04.30 22:07 José Fonseca wrote:
... Next in mach64_drv.h, let's try the following definitions
the DMA test fails), but you'll need to cold
restart to get DMA back.
--
Leif Delgass
http://www.retinalburn.net
#if MACH64_USE_DMA
...
#endif /* MACH64_USE_DMA */
#endif
to disable all that section.
Well, Peter, although the bissection algorithm can take some interations,
if the initial conditions are met, it's guaranteed that it converges! ;-)
José Fonseca
--
Leif Delgass
http
if the jerkiness goes away.
Also, could you try this:
set MACH64_USE_DMA back to zero in mach64_drv.h, then change line 539 of
mach64_state.c from:
if ( mach64_do_wait_for_fifo( dev_priv, 16 ) 0 )
to:
if ( mach64_do_wait_for_idle( dev_priv ) 0 )
...and see if you still get a lockup.
--
Leif
On Tue, 30 Apr 2002, Kaz Sasayama wrote:
Thank you for the explanation. I see the point now.
Leif Delgass wrote:
On Fri, 26 Apr 2002, Kaz Sasayama wrote:
I'm now trying mach64-0-0-4-branch with Rage Mobility-M PCI (LR). The
compiled X server does not work in a setting more than
On Sun, 28 Apr 2002, Peter Andersson wrote:
Leif Delgass wrote:
On Sun, 28 Apr 2002, Peter Andersson wrote:
Well, it looks like the _dispatch_clear completes without a
problem. Could you run ksymoops on the syslog? That will decode the back
trace from the oops (it's best to run
On Sun, 28 Apr 2002, Leif Delgass wrote:
On Sun, 28 Apr 2002, Peter Andersson wrote:
Leif Delgass wrote:
On Sun, 28 Apr 2002, Peter Andersson wrote:
Well, it looks like the _dispatch_clear completes without a
problem. Could you run ksymoops on the syslog? That will decode
/listinfo/gatos-devel
___
Gatos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/gatos-devel
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
with a black background? If you saw
them being drawn, did you see them moving before the lockup? When the
lockup happened, did the screen blank or did it just freeze?
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED
a lockup. Setting a
breakpoint at the SwapBuffers would let you get a frame of output at a
time, but you'd need to compile gears from the Mesa source with debugging
symbols.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL
On Sun, 28 Apr 2002, Leif Delgass wrote:
On Mon, 29 Apr 2002, José Fonseca wrote:
On 2002.04.29 00:33 Peter Andersson wrote:
hmmm.. OK, here are some questions for you: Did you actually see the
gears being drawn, or just the window with a black background?
I saw the gears
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
?).
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
before DMA will
work again.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Sun, 28 Apr 2002, Leif Delgass wrote:
If it works, you should see the same 7 VERTEX_ register values in the
system log before and after the test.
Sorry, I meant to say that you should see all zeros for the registers
before the transfer and 0x, 0x, etc. after the transfer
/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
and back
buffers, but the current branch allocates enough for a 32bpp depth buffer.
I have code to fix that, but I need to clean it up before checking it in.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https
with PCI I use:
u32 *p = (u32 *) buf-address
Jose, you almost had it before, it's just a matter of using the right
types and cast. I'll try and send you a patch soon when I get things
cleaned up a bit.
--
Leif Delgass
http://www.retinalburn.net
the #define of MACH64_USE_DMA to 1 in mach64_drv.h
in the DRM. If you're updating your source from cvs, you should probably
do a fresh 'make World' as some headers have changed here and there.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel
I have in hand, but as Gareth has said before, get it working-
I'm just waay to busy to have completed what I had in mind up until recently.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https
Fonseca
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED
caused
by a fifo overflow. I don't expect this to be as fast as doing the
register writes client side, so I'm not too worried about the performance
hit.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https
On Sun, 21 Apr 2002, José Fonseca wrote:
On 2002.04.21 19:40 Leif Delgass wrote:
On Sun, 21 Apr 2002, José Fonseca wrote:
We just need to add the fifo check now.
I've just add it but it makes gears drop from 222 to 185 fps in my
system.
I don't know if this is caused
to the renderer string, but the infrastructure needed for the DDX and
Mesa driver are there now.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
* macros yet, though.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Sat, 20 Apr 2002, José Fonseca wrote:
On 2002.04.20 21:21 Leif Delgass wrote:
Jose,
I added the remaining bits to copy the agp texture region info to the
drm.
It's not used, but the information is there in case we need it later.
I hope you don't mind, but I took the liberty
On Fri, 19 Apr 2002, José Fonseca wrote:
On 2002.04.19 04:37 Leif Delgass wrote:
On Thu, 18 Apr 2002, José Fonseca wrote:
[snip]
I didn't take over the DMA part, but that will eventually happen. For
now
I'm moving all register programming from GL driver to the DRM
help you can provide would be greatly
appreciated.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
merge to the DRI trunk. I have a mini build
HOWTO for the branch to supplement the compilation guide on the DRI site
here:
http://retinalburn.net/linux/dri_HOWTO.html
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
or framebuffer images showing
through in the textures using software fallback. I was thinking that
perhaps Mesa was reading from the wrong place in the framebuffer to do
alpha blending for the fallbacks.
--
Leif Delgass
http://www.retinalburn.net
was regarding this?
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On 10 Apr 2002, Michel Dänzer wrote:
On Wed, 2002-04-10 at 01:01, Leif Delgass wrote:
The mach64 can only use a 16-bit depth buffer, even with a 32bpp framebuffer,
so I'm also interested in this. I couldn't see a way to request a
smaller buffer from the XFree framebuffer manager
blending is enabled, but no one has implemented it yet.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
being disabled.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
MaxTextureLevels = 9 (256x256)
This should apply to Rage128 and Radeon as well. Am I missing something
here?
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri
On Wed, 27 Mar 2002, Daryll Strauss wrote:
On Wed, Mar 27, 2002 at 04:00:55PM -0500, Leif Delgass wrote:
On Wed, 27 Mar 2002, Alexander Stohr wrote:
So we'd use
mach64Screen-cpp for the calculation instead of a fixed 4
bytes/texel?
Then the comparison would
down to 512x512 max texture
size to speedup quake, for example, but the default will allow the max
texture size supported by the card to be used with a single texture unit.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
/\ \_\ \_\ \__U___just not everything
[EMAIL PROTECTED]o__/ \___/ \___/at the same time!
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http
if it's in your version.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Tue, 26 Mar 2002, Leif Delgass wrote:
On Tue, 26 Mar 2002, Felix Kühling wrote:
Hi,
GL ScreenSavers: perfect
Not quite! The pipe demo shows only one segment of the pipe at a time.
I never see the whole pipe. I'm using xscreensaver 3.34-1.1 (Debian
woody).
I see problems
On Tue, 26 Mar 2002, Leif Delgass wrote:
On Tue, 26 Mar 2002, Leif Delgass wrote:
On Tue, 26 Mar 2002, Felix Kühling wrote:
Hi,
GL ScreenSavers: perfect
Not quite! The pipe demo shows only one segment of the pipe at a time.
I never see the whole pipe. I'm using
(the mountains), but the rest is just a mangle of pixels, which
sort-of look like Tux...
Tristan
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http
-20020325-0822-i386-Linux.tar.bz2
I have reverted to
mach64-20020322-1223-i386-Linux.tar.bz2
Tristan
Il lun, 2002-03-25 alle 16:42, Leif Delgass ha scritto:
That sounds like what we were seeing before Jose's fix for depth scaling.
Which snapshot are you using?
--
Leif Delgass
fails
(it's the only one that fails). We haven't merged any recent Mesa changes
from the trunk yet, so I don't know if there's a fix already. I'm
attaching the output from glean.
--
Leif Delgass
http://www.retinalburn.net
texCombine: FAIL r5g6b5, db, z16, win+pmap, id 35
expected 1, 1
with alpha
blending enabled.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
to GL_EXT_texture_env_dot3.
With fallback for env_combine, we get this as a fallback as well, right?
GL_ARB_transpose_matrix
Done.
Included in Mesa 4.x, just export the extension, right?
--
Leif Delgass
http://www.retinalburn.net
___
Dri
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
are sequential registers, and it
could pump up our gears numbers a bit. ;) I'll see if I can get it to
work with MMIO and if so, we could try those vertex formats with DMA as
well.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL
*= rhw;
+#endif
}
}
-#ifdef MACH64_PREMULT_TEXCOORDS
- v-v.u0 *= v-v.w;
- v-v.v0 *= v-v.w;
-#endif
}
if (DO_TEX1) {
if (DO_PTEX) {
--
Leif Delgass
http://www.retinalburn.net
support mipmapping either, you just get a yellow triangle.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
issue that I've
noticed (with the old driver too) is that texture fallbacks with
single-buffering have problems where old textures show through.
--
Leif Delgass
http://www.retinalburn.net
-- Forwarded message --
Date: Thu, 7 Mar 2002 22:40:14 -0500 (EST)
From: Leif Delgass [EMAIL
|DEBUG_IOCTLS)
The performance penalty for keeping the printfs compiled in seems insigificant
so far...
Keith
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http
though it's included.
This is probably just the result of work being started on DMA but never
finished.
[snip]
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
On Mon, 4 Mar 2002, José Fonseca wrote:
On 2002.03.04 19:13 Leif Delgass wrote:
On Mon, 4 Mar 2002, José Fonseca wrote:
But why does the number of levels has to do with the maximum texture
size?
As I understand it, a mipmapped texture is composed of several levels
the Mesa texture image structure. I fixed the one
reference to the context var in texmem to use the Mesa value.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
in the template code and
the register programming in _tris.c and make sure we're giving the
hardware the right data in the right format.
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net
it gets to swap buffers.
Any ideas?
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
is the tris/vb stuff, which looks very
different now
--
Leif Delgass
http://wwwretinalburnnet
m64-20022028.diff.gz
Description: mach64 Mesa driver diff
On Thu, 28 Feb 2002, José Fonseca wrote:
On 2002.02.28 10:56 Leif Delgass wrote:
Jose,
I've been hacking on the tex/texmem/texstate stuff. I just did an update
and it looks like you've done much of the same thing, so I'm sending a
diff for you to compare to your changes. I'm going
dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None
0x28 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow
0x29 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow
0x2a 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow
--
Leif Delgass
http
://mail.yahoo.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https
can give a better advice than a CVS
user list since you know the code in question.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
On Mon, 25 Feb 2002, José Fonseca wrote:
On 2002.02.25 00:58 Leif Delgass wrote:
In investigating texture environment modes on the mach64, I've discovered
that the card can't modulate fragment and texture alpha values (this is
confirmed by the docs, experimentation, and comments
201 - 300 of 334 matches
Mail list logo
