the endianess fixes.
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
these a try once I've updated my tree, I was testing from
binaries before.
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by: Jabber - The world's fastest growing
real-time communications platform! Don't just IM
On 17 Jul 2002, Michel Dänzer wrote:
On Tue, 2002-07-16 at 20:17, Leif Delgass wrote:
On Tue, 16 Jul 2002, Keith Whitwell wrote:
Well, it's not high on my list. I don't think flat-shading is used that
often, and the changes don't have any effect on smooth shading. Actually
On Wed, 17 Jul 2002, Leif Delgass wrote:
On 17 Jul 2002, Michel Dänzer wrote:
On Tue, 2002-07-16 at 20:17, Leif Delgass wrote:
On Tue, 16 Jul 2002, Keith Whitwell wrote:
Well, it's not high on my list. I don't think flat-shading is used that
often, and the changes don't
On Tue, 16 Jul 2002, Leif Delgass wrote:
These look very good to me, I'll commit them. Leif, can you verify they
don't break x86? I'd be very surprised, but it wouldn't be the first
time. :)
I'll give these a try once I've updated my tree, I was testing from
binaries before
://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored
It also looks like bus-mastering capabilities were added starting with the
264VT-B and Rage II. That would include Rage IIc, but not plain 264VT.
However, the 2D driver doesn't currently use bus mastering.
On Wed, 17 Jul 2002, Leif Delgass wrote:
The Rage IIc is part of the more recent GT
hand at combining these into a single patch for all the
drivers?
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
On Wed, 17 Jul 2002, Leif Delgass wrote:
On 17 Jul 2002, Michel Dänzer wrote:
On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon
and r200.
Great job! The clipping problems I originally reported
, the problem probably went unnoticed anyway.
Thanks for the clipping fix Keith, your one line beat my original 'fix' by
a mile!
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http
-support/linux/drm/kernel/drmP.h make me
suspect that you've forgotten to commit some of your work, Keith?
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer
On 17 Sep 2002, Michel Dänzer wrote:
On Die, 2002-09-17 at 20:14, Leif Delgass wrote:
Don't you want to wait for the vblank _after_ the flip ioctl? That way
you won't draw on the buffer being currently scanned until the vblank
indicates the buffers toggled.
That may be true
On Tue, 17 Sep 2002, Leif Delgass wrote:
On 17 Sep 2002, Michel Dänzer wrote:
BTW, with the current Radeon page flipping code without interrupts, how
does it avoid flickering?
Not at all, the flip occurs immediately.
But even if the card can process the flip before vblank, doesn't
On 17 Sep 2002, Michel Dänzer wrote:
On Die, 2002-09-17 at 21:29, Leif Delgass wrote:
On 17 Sep 2002, Michel Dänzer wrote:
On Die, 2002-09-17 at 20:14, Leif Delgass wrote:
Don't you want to wait for the vblank _after_ the flip ioctl? That way
you won't draw on the buffer being
their
offscreen regions can be freed?
The way I did this in my mach64 DRI+gatos patch is to call
xf86FreeOffscreenLinear(pPriv-linear) in the TransitionTo3d. I took
this from the tdfx driver and it seems to work, although I'm not sure it's
100% correct.
--
Leif Delgass
http://www.retinalburn.net
mean that usual Mach64 DRI binaries have all the xv things (without
tvout) or what?
Sergey
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
A couple of additions I forgot:
2D XFree86 Driver: ati_drv.o + atimisc_drv.o
- Fog is disabled if alpha blending is enabled.
On Fri, 11 Oct 2002, Leif Delgass wrote:
I think I can fill in a few blanks for mach64:
Card names:
3D Rage Pro
All-in-Wonder Pro
Xpert 98/LCD/XL/@Play/@Work
3D
in memory of the ring and buffers.
Well :) Hope it could be of some use!
I don't see anything unusual here -- except the lockup, of course.
Determining the root cause of the lockup is the difficult part. Have you
found any Mesa demos that don't lock up with either sync or async dma?
--
Leif Delgass
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
--- feature_table.orig.html Sat Oct 19 11:38:02 2002
+++ feature_table.html Sat Oct 19 12:45:31 2002
the first
problem was a problem in xfree86-gdb, but it seemed in general that
function pointers were getting confused when a module was reloaded.
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by: See the NEW Palm
in the locking/sync code, or should multi-adapter
multi-head not be expected to work out of the box ? From what I can
tell, the tdfx driver seems to be the only one that supports multiple
devices in the DRM.
--
Leif Delgass
http://www.retinalburn.net
-- Forwarded message --
Date
fields in drm_buf_t and drmAddMap only works for AGP
or scatter-gather PCI mem. What do you think?
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com
?
The X server is built from DRI-CVS two days ago with the XV patches
added from Leif Delgass homepage.
cat /var/log/XFree86.0.log: XFree86
Version 4.2.0 (DRI mach64 branch) / X Window System (protocol Version
11, revision 0, vendor release 6600) Release Date: 18 January 2002
On Wed, 27 Nov 2002, Svante Signell wrote:
Leif Delgass writes:
Have you tried a lower resolution?
Not yet.
Try restarting X with 1024x768@16bpp for a while and see if you still have
the same problem.
If it's some sort of memory leak, I'd
expect that you'd run into it eventually
On Thu, 28 Nov 2002, Svante Signell wrote:
Leif Delgass writes:
On Wed, 27 Nov 2002, Svante Signell wrote:
Leif Delgass writes:
Have you tried a lower resolution?
Not yet.
Try restarting X with 1024x768@16bpp for a while and see if you still have
the same problem
.
According to section 4.1.8 of the OpenGL 1.4 spec: Initially, dithering
is enabled -- so that should always be the initial default.
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven
, you can actually save
memory if the application only needs 16bpp for a texture and specifies an
appropriate sized format.
--
Leif Delgass
http://www.retinalburn.net
---
This SF.net email is sponsored by: Microsoft Visual Studio.NET
, but serializable to a
user readable/editable file?
--
Leif Delgass
http://www.retinalburn.net
---
This SF.net email is sponsored by: Microsoft Visual Studio.NET
comprehensive development tool, built to increase your
productivity. Try a free
On Tue, 3 Dec 2002, Leif Delgass wrote:
On Tue, 3 Dec 2002, Brian Paul wrote:
There was previously a dependency on the screen color depth when
choosing the texture format in the radeon driver.
I think that may have been a carry-over from the r128 (or tdfx?) driver
which may
in r128_state.c need to cause an update of the texture state.
I'll keep digging...
--
Leif Delgass
http://www.retinalburn.net
---
This SF.net email is sponsored by: Microsoft Visual Studio.NET
comprehensive development tool, built to increase
. Better luck on the next attempt...
--
Leif Delgass
http://www.retinalburn.net
---
This SF.net email is sponsored by: Microsoft Visual Studio.NET
comprehensive development tool, built to increase your
productivity. Try a free online hosted
]
https://lists.sourceforge.net/lists/listinfo/dri-patches
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven
requirement in XFree86 to
be bumped if new functionality is required from a future agpgart version
(which again is assumed to also retain the original interface).
I plan to commit this to the DRI cvs HEAD. Please apply this to XFree86
cvs so it can be included in XFree86 4.3.0. Thanks.
--
Leif
On Tue, 10 Dec 2002, Dave Jones wrote:
On Tue, Dec 10, 2002 at 04:21:03PM -0500, Leif Delgass wrote:
--- xc/programs/Xserver/hw/kdrive/linux/agp.c 9 Apr 2001 16:27:42 -
1.1.1.1
+++ xc/programs/Xserver/hw/kdrive/linux/agp.c 10 Dec 2002 20:51:02 -
@@ -120,9
if you can..
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org
synchronous with vblank... The
Hardware already does that for you.
So, how do you delay the flip-blit to the vblank but NOT delay other
rendering? I think that would also make it difficult to implement things
like {GLX,WGL}_SGI_swap_control or {GLX,WGL}_OML_sync_control.
--
Leif Delgass
of the multiple repositories causing confusion... ;)
On Fri, 13 Dec 2002, Leif Delgass wrote:
On Fri, 13 Dec 2002, Leif Delgass wrote:
On Fri, 13 Dec 2002, Ian Romanick wrote:
On Fri, Dec 13, 2002 at 05:43:51PM -0500, Leif Delgass wrote:
FYI, I noticed this recent patch from Arjan van de
7000/VE or Radeon Mobility (M6?) ChipID.
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http
get permission to implement texture
compression. Some older apps look for that instead of
EXT_texture_compression_s3tc, e.g. Quake 3.
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek
for combine3/4 extensions - not all
blend modes supported
However, I still see the same corruption reported before. This could be
in part because of the missing cube map support, but it looks to me like
something is causing vertex data corruption. Just a guess.
--
Leif Delgass
http
On Tue, 21 Jan 2003, Brian Paul wrote:
Ian Romanick wrote:
Leif Delgass wrote:
On Thu, 2 Jan 2003, Daniel Vogel wrote:
A bit unrelated:
Log: OpenGL Error: GL_INVALID_ENUM (UOpenGLRenderDevice::Unlock)
(if anyone wants the full log let me know)
On OS X 10.2.3
On Tue, 21 Jan 2003, Leif Delgass wrote:
On Tue, 21 Jan 2003, Brian Paul wrote:
Ian Romanick wrote:
Leif Delgass wrote:
On Thu, 2 Jan 2003, Daniel Vogel wrote:
A bit unrelated:
Log: OpenGL Error: GL_INVALID_ENUM (UOpenGLRenderDevice::Unlock)
(if anyone wants
On Tue, 21 Jan 2003, Ian Romanick wrote:
Brian Paul wrote:
Leif Delgass wrote:
On Thu, 2 Jan 2003, Daniel Vogel wrote:
glTexEnvi( GL_TEXTURE_ENV, GL_OPERAND2_RGB, GL_SRC_COLOR );
This is indeed one of the sources of the GL_INVALID_ENUMs; however, it
appears to be a bug
of NV_vertex_array_range or
ATI_vertex_array_object? I assume there's a fallback path since I don't
see any GL errors related to those extensions.
--
Leif Delgass
http://www.retinalburn.net
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't
writeable.
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel
On Tue, 28 Jan 2003, Ian Romanick wrote:
The thing that makes XML worse is that it gives people an extra degree
of freedom. This amounts to giving people more rope with which to shoot
themselves in the foot.
LOL.
/me holds rope
/me looks at foot
/me scratches head
--
Leif Delgass
http
, then copy back?
To be honest, I don't know the gory details of the Mesa software
rasterizer yet, but any primitives needing a texture application that
can't be done in hardware would be completely software rendered and
written to the framebuffer, I think.
--
Leif Delgass
http://www.retinalburn.net
the common texmem
code.
At any rate, I can put a patch together for review, but I wanted to see if
there's anything I'm missing here.
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by:
SourceForge Enterprise
as glTexImage2D. They always upload the entire texture image --
there was a comment I remeber seeing about the subimage index calculations
being wrong. Fixing this to only upload the subimage would help the
performance of glTexSubImage2D.
--
Leif Delgass
http://www.retinalburn.net
On Fri, 31 Jan 2003, Arkadi Shishlov wrote:
On Fri, Jan 31, 2003 at 04:33:36PM -0500, Leif Delgass wrote:
Actually, iirc, all the drivers actually implement glTexSubImage2D the
same way as glTexImage2D. They always upload the entire texture image --
there was a comment I remeber seeing
On Fri, 31 Jan 2003, Ian Romanick wrote:
Leif Delgass wrote:
There are also a few failing assertions related to placeholder texture
objects. In driTexturesGone, we need to set t-heap = heap or else the
assertion that t-heap != NULL fails in driDestroyTextureObject when
destroying
. :)
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif
will apply it to the branch.
I need to do some more testing on the Rage 128 driver, but so far things
seem to be working except for the problem in the fire Mesa demo, which is
still there. It kind of looks like a texture coordinate problem, but I'm
not sure yet.
--
Leif Delgass
http
for Rage 128.
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri
Attached is the patch with the modifications you suggested.
--Leif
On Mon, 3 Feb 2003, Ian Romanick wrote:
Leif Delgass wrote:
It this looks OK, I will apply it to the branch.
I've poked around with the patch, and it looks good. There are only two
things that I would change
-Backspace works and I can restart X without a problem. I've also
seen that with same behavior with AGP Radeon 7500 from time to time.
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by:
SourceForge Enterprise
wrong so I thought
I'd point this out in case anyone else was operating under the same
assumptions. ;)
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld
to XDestroyWindow(),
which the dri doesn't know anything about.
Keith
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http
).
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing
On Wed, 5 Feb 2003, Arkadi Shishlov wrote:
On Tue, Jan 28, 2003 at 11:01:53PM -0500, Leif Delgass wrote:
On Wed, 29 Jan 2003, Arkadi Shishlov wrote:
- 'Texture environment modes: GL_BLEND is done in software..' - mean
glTexEnv(GL_BLEND) is software. GL_DECAL is hw accelerated
wanted to see if you had something already.
Also, should I go ahead and commit my revised texmem patch?
--
Leif Delgass
http://www.retinalburn.net
Index: radeon_context.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon
On Wed, 5 Feb 2003, Keith Whitwell wrote:
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar circumstances,
but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as
a magic stamp value never gets updated because the X
:
Leif Delgass wrote:
On Wed, 5 Feb 2003, Keith Whitwell wrote:
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar
circumstances, but goes into an infinite loop inside
DRI_VALIDATE_DRAWABLE_INFO(), as a magic stamp value never gets
On Wed, 5 Feb 2003, Ian Romanick wrote:
Leif Delgass wrote:
Ian, now that you've merged in the software support for combine3 from the
Mesa trunk, I'm trying to get it working in hardware on R100 with texmem
(impatient as I am ;) ). I don't have Radeon docs, so I'm guessing about
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld
://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored
+ LinuxWorld ÿomething 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
On Thu, 6 Feb 2003, Felix Kühling wrote:
On Wed, 5 Feb 2003 20:17:57 -0500 (EST)
Leif Delgass [EMAIL PROTECTED] wrote:
Hurrah! ... this fixes the vertex data corruption in the UT2003 opening
screen. There's still vertex problems in game (though not quite as much).
The remaining
On Wed, 5 Feb 2003, Keith Whitwell wrote:
Leif Delgass wrote:
Hurrah! ... this fixes the vertex data corruption in the UT2003 opening
screen. There's still vertex problems in game (though not quite as much).
The remaining problems may be because of cube mapping (I'm testing on
R100
On Wed, 5 Feb 2003, Leif Delgass wrote:
Also, should I go ahead and commit my revised texmem patch?
Yes.
OK, will do. Do you want to commit your patch for combine3 to texmem? I
don't have an R200, so I can't test that, but it looks like it should be
easy to add there too
mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See
changes couldn't also go
into the trunk.
Done.
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
, this should not be the case, need to ask an
* engineer at Intel.
*/
Until someone can fix the span reads, I'll assume destination alpha isn't
working. I'll fix this one.
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET
the diff
didn't apply cleanly enough to wing it...
Anyone else?
Keith
Here's a hand-merged diff against mesa-4-0-4-branch. How does this look?
--
Leif Delgass
http://www.retinalburn.net
Index: r200_texstate.c
===
RCS file
and GATOS trees.
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri
. Comments?
It also looks to me like there could be a memory leak on pBackClipRects in
driDestroyDrawable(). It looks like pBackClipRects should be freed there
(if non-NULL) along with pClipRects. Is this freed somewhere that
I'm missing?
--
Leif Delgass
http://www.retinalburn.net
to that list to
project members. Of course, there may be people with commit access that
aren't subscribed. Is there a way to restrict it to sourceforge accounts
rather than the subscriber list?
--
Leif Delgass
http://www.retinalburn.net
On Fri, 14 Feb 2003, Ian Romanick wrote:
Leif Delgass wrote:
On Fri, 14 Feb 2003, David Dawes wrote:
[snip]
There are some more serious things holding up 4.3, including the issue
that Leif mentioned here a couple of days ago. I haven't seen anyone
comment on his proposed
to me it would be more intrusive and require more checking for
side-effects.
--
Leif Delgass
http://www.retinalburn.net
Index: dri_util.c
===
RCS file: /cvs/xc/lib/GL/dri/dri_util.c,v
retrieving revision 1.5
diff -u -r1.5
On 15 Feb 2003, Eric Anholt wrote:
On Tue, 2003-02-11 at 20:11, Leif Delgass wrote:
I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been
updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've
updated the mach64 driver to Mesa 5 based on the changes
On Sat, 15 Feb 2003, Mike A. Harris wrote:
On Fri, 14 Feb 2003, Leif Delgass wrote:
I could do it, but I don't think it's a good idea to restrict those
who are non-members of the list. Cross postings from the xfree86 lists
are sometimes useful.
Alan.
What about dri-patches
Speaking of Dri-patches... ;)
There seems to be a problem with the @users.sourceforge.net wildcard
address in the subscriber list. I'm subscribed to Dri-patches, but not
with my sourceforge email.
--
Leif Delgass
http://www.retinalburn.net
-- Forwarded message --
Date: Sat
machine and be done with it. We waste more time and bandwidth
talking about what should be done (with the list) then actually doing
what really should be done (with dri). Just my thoughts ...
On Sat, 15 Feb 2003, Leif Delgass wrote:
On Sat, 15 Feb 2003, Mike A. Harris wrote
://lists.sourceforge.net/lists/listinfo/dri-patches
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel
of the attached patch is trivial additions of
DRM_ERR, DRM_CURRENTPID, etc. and a couple of whitespace tweaks.
--
Leif Delgass
http://www.retinalburn.net
Index: linux/drm/kernel/drmP.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver
10 days ago). I'm not sure if the problem that fixed could cause a
lockup, but you might want to try building a DRM from current X cvs and
see if it makes a difference.
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email
On Tue, 18 Feb 2003, [iso-8859-15] José Fonseca wrote:
On Mon, Feb 17, 2003 at 08:15:02PM -0500, Leif Delgass wrote:
As I was doing some minor cleanups in the mach64 drm in the new branch, I
made some additional search and replace conversions of the mach64 DRM to
the os independence macros
On Tue, 18 Feb 2003, Leif Delgass wrote:
My memory is failing: this might still be usefull for Xv, isn't it?
Maybe, maybe not. DMA for XVideo seems to be of questionable value,
judging from the Rage 128 driver. Plus the fact that you have to
wait/sync when switching between GUI masters
dwords following). If the
verify passes, we copy the command as in the last line of the loop above,
but then we need to __copy_from_user up to 7 dwords of data into the
destination without reading it. So it's a loop of alternating 1 dword
read/verify/write and 1-7 dwords straight copy.
--
Leif
On Wed, 19 Feb 2003, [iso-8859-15] José Fonseca wrote:
On Tue, Feb 18, 2003 at 06:30:40PM -0500, Leif Delgass wrote:
I also made some other changes to the copy/verify:
I added a check to the ioctl handler (mach64_dma_vertex) to check that the
vertex buffer has an integral number
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-patches
--
Leif Delgass
http://www.retinalburn.net
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can
On Wed, 19 Feb 2003, Ian Romanick wrote:
Leif Delgass wrote:
Ian, this commit includes references to rmesa-hw.cube[], which isn't in
radeon_context.h yet. I don't see any reason not to commit the entire
cube map patch, but leave the extension disabled. I haven't had time
On Thu, 20 Feb 2003, Leif Delgass wrote:
On Thu, 20 Feb 2003, Philip Brown wrote:
On Thu, Feb 20, 2003 at 09:12:04PM +, Philip Armstrong wrote:
Using the debs at http://people.debian.org/~daenzer/dri-trunk-sid/ on
Debian unstable and the latest demo release of UT2003 (v2206
corruption in
the intro cinematic in the R100 driver was fixed. However, there are
still vertex problems that appear to be in the R100 driver to track down.
I can't test R200, so I'm not sure what the status is there.
--
Leif Delgass
http://www.retinalburn.net
?
The 3D app is burning a lot of CPU and the system is otherwise running.
At the point the 3D is killed (kill -9 etc) the box hangs solid
Classical chip crash or lockup. :\
--
Leif Delgass
http://www.retinalburn.net
---
This SF.net
On 22 Feb 2003, Michel Dänzer wrote:
On Sam, 2003-02-22 at 22:16, Leif Delgass wrote:
On 22 Feb 2003, Michel Dänzer wrote:
On Sam, 2003-02-22 at 00:48, Alan Cox wrote:
I do wonder if the register writes in RADEONSetCursorPosition() could
interfere with the CP to cause FIFO
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
---
This SF.net email is sponsored by: SlickEdit Inc
201 - 300 of 334 matches
Mail list logo
