Henry Worth wrote:
> Henry Worth wrote:
>
>>
>> I gave the driver a quick try without the HOST_BIG_ENDIAN_EN bit
>> set and with the PACK*LE macros. And, the 2-d stuff seems to be working
>> and the textures do need the PACK*LE macros. So, perhaps the bit only
>> impacts the DMA blits used to loa
On 17 Jul 2002, Michel Dänzer wrote:
> On Wed, 2002-07-17 at 02:10, Henry Worth wrote:
> >
> > Attached are patches for r128 on ppc. Rather little change to the r128 code
> > was needed once I gave up on the char arrays for the vertex colors, and
> > embraced the hw specific ordered named fields
On Wed, 2002-07-17 at 03:57, Henry Worth wrote:
> Michel Dänzer wrote:
>
> >
> >Thank you for breaking the radeon and mach64 drivers on big endian
> >machines. ;) We've got to find a better solution here, I must confess I
> >still don't understand how it can not work with PACK*LE though. Maybe
>
Henry Worth wrote:
>
> I gave the driver a quick try without the HOST_BIG_ENDIAN_EN bit
> set and with the PACK*LE macros. And, the 2-d stuff seems to be working
> and the textures do need the PACK*LE macros. So, perhaps the bit only
> impacts the DMA blits used to load the texture subimages?
>
>
Slava Polyakov wrote:
> On July 16, 2002 06:19 pm, you wrote:
>
>>Slava Polyakov wrote:
>>
>>>On July 16, 2002 04:15 pm, you wrote:
>>>
Every so often (for example after 1hr of gameplay) a glx program like
RTCW or WINE running SOF2 freezes... now, Only the program however, X is
fine.
Michel Dänzer wrote:
>
>Thank you for breaking the radeon and mach64 drivers on big endian
>machines. ;) We've got to find a better solution here, I must confess I
>still don't understand how it can not work with PACK*LE though. Maybe
>the HOST_BIG_ENDIAN_EN bit in the DP_DATATYPE register (set i
Michel Dänzer wrote:
>On Wed, 2002-07-17 at 02:10, Henry Worth wrote:
>
>>Attached are patches for r128 on ppc. Rather little change to the r128 code
>>was needed once I gave up on the char arrays for the vertex colors, and
>>embraced the hw specific ordered named fields provided in the *_color_t
On Wed, 2002-07-17 at 02:10, Henry Worth wrote:
>
> Attached are patches for r128 on ppc. Rather little change to the r128 code
> was needed once I gave up on the char arrays for the vertex colors, and
> embraced the hw specific ordered named fields provided in the *_color_t
> provided by t_dd_ve
Leif Delgass wrote:
>On 17 Jul 2002, Michel Dänzer wrote:
>
I just updated to today's build and texture colors look fine on r128 in
x86. Also, we had reports that the changes made in Mesa on the trunk
(which we merged into the mach64 branch) fixed textures on ppc for mach64,
whic
Attached are patches for r128 on ppc. Rather little change to the r128 code
was needed once I gave up on the char arrays for the vertex colors, and
embraced the hw specific ordered named fields provided in the *_color_t
provided by t_dd_vertex.h.
1) Revert PACK*LE from texutil.c as per previous
On Wed, Jul 17, 2002 at 01:37:01AM +0200, Michel D?nzer wrote:
> On Wed, 2002-07-17 at 01:19, Steven Walter wrote:
> > I have a Radeon 7500 QW, and also get the vt-switch bug. I'm running
> > DRI cvs trunk as of a few days ago.
> >
> > Something interesting that I have found is a correlation to
On 17 Jul 2002, Michel Dänzer wrote:
> > >I just updated to today's build and texture colors look fine on r128 in
> > >x86. Also, we had reports that the changes made in Mesa on the trunk
> > >(which we merged into the mach64 branch) fixed textures on ppc for mach64,
> > >which has a choose text
On Wed, 2002-07-17 at 01:19, Steven Walter wrote:
> I have a Radeon 7500 QW, and also get the vt-switch bug. I'm running
> DRI cvs trunk as of a few days ago.
>
> Something interesting that I have found is a correlation to the xvidmode
> extension. With it enabled, the first switch-away/switch-
On July 16, 2002 06:19 pm, you wrote:
> Slava Polyakov wrote:
> > On July 16, 2002 04:15 pm, you wrote:
> >>Every so often (for example after 1hr of gameplay) a glx program like
> >> RTCW or WINE running SOF2 freezes... now, Only the program however, X is
> >> fine. However it freezes my mouse and
I have a Radeon 7500 QW, and also get the vt-switch bug. I'm running
DRI cvs trunk as of a few days ago.
Something interesting that I have found is a correlation to the xvidmode
extension. With it enabled, the first switch-away/switch-back will
cause a hard lock. The screen mostly restores, bu
On Wed, 2002-07-17 at 00:34, Henry Worth wrote:
> Leif Delgass wrote:
>
> >On Tue, 16 Jul 2002, Henry Worth wrote:
> >
> >>Have there been any reports of r128 texture color problems on x86 with
> >>recent CVS? Or that it even works?
> >>
> >
> >I just updated to today's build and texture colors l
On Tue, 2002-07-16 at 23:02, Charl P. Botha wrote:
>
> The card is a Radeon M7 (LW) in a noname brand laptop with an i845 chipset
> and a Northwood P4.
Interesting, the box I saw the problem on has an Intel 850/820 chipset.
IIRC earlier reports of this problem were from on Athlons though.
> So
Leif Delgass wrote:
>On Tue, 16 Jul 2002, Henry Worth wrote:
>
>>Have there been any reports of r128 texture color problems on x86 with
>>recent CVS? Or that it even works?
>>
>
>I just updated to today's build and texture colors look fine on r128 in
>x86. Also, we had reports that the changes m
On Tue, 2002-07-16 at 17:56, José Fonseca wrote:
> I'm CC'ing to dri-devel as well to get a broaded audience.
>
> On Tue, Jul 16, 2002 at 05:28:37PM +0200, dylan wrote:
> > Good plan, The DRM module is not happy and throws a bit of a fit.
> >
> > Here is a small snippet showing the exact respon
Slava Polyakov wrote:
> On July 16, 2002 04:15 pm, you wrote:
>
>>Every so often (for example after 1hr of gameplay) a glx program like RTCW
>>or WINE running SOF2 freezes... now, Only the program however, X is fine.
>>However it freezes my mouse and kdb... if I telnet in and kill the
>>offending
On Tue, 16 Jul 2002, Henry Worth wrote:
> Have there been any reports of r128 texture color problems on x86 with
> recent CVS? Or that it even works?
I just updated to today's build and texture colors look fine on r128 in
x86. Also, we had reports that the changes made in Mesa on the trunk
(whi
Err, I forgot those attachments. Here they are, along with the complete
mail for future reference:
Dear list,
This is just to add another sample to the Radeon switch to VT and back X
freeze bug, which is apparently known.
I'm running the XFree86 4.2.0pre1v1 Debian packages on a Debian Woody sy
On Tue, 16 Jul 2002, Keith Whitwell wrote:
> Can someone out there check this quickly?
>
> In radeon.h in the 2d driver, the size of the radeon mmio area is defined as
> 0x8 - however, on my r200 at least, /proc/pci shows the area as being
> 1/8th that size:
>
>Bus 1, device 0, fun
Dear list,
This is just to add another sample to the Radeon switch to VT and back X
freeze bug, which is apparently known.
I'm running the XFree86 4.2.0pre1v1 Debian packages on a Debian Woody system
with a Radeon driver snapshot of 20020715 as kindly supplied by dri.sf.net.
The card is a Radeon
Keith Whitwell wrote:
> Can someone out there check this quickly?
>
> In radeon.h in the 2d driver, the size of the radeon mmio area is
> defined as 0x8 - however, on my r200 at least, /proc/pci shows the
> area as being 1/8th that size:
>
> Bus 1, device 0, function 0:
> ... (omitte
I'm in the process of finishing up some patches for r128 on PPC. One
problem I've run into that conflicts with the radeon PPC fixes is
the choosing and loading of textures. For radeon the PACK_COLOR*
macros in extra/Mesa/src/texutil.c were changed to PACK_COLOR*LE
versions. With the *LE versions
On Tue, 2002-07-16 at 15:58, Keith Whitwell wrote:
> Can someone out there check this quickly?
>
> In radeon.h in the 2d driver, the size of the radeon mmio area is defined as
> 0x8 - however, on my r200 at least, /proc/pci shows the area as being
> 1/8th that size:
>
>Bus 1, device
I've forgotten to say what was my card: ati radeon 8500 QL
---
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
_
On Tue, Jul 16, 2002 at 01:58:29PM -0600, Keith Whitwell wrote:
> In radeon.h in the 2d driver, the size of the radeon mmio area is defined
> as 0x8 - however, on my r200 at least, /proc/pci shows the area as
> being 1/8th that size:
>
> Bus 1, device 0, function 0:
> ... (omitted) ..
Keith Whitwell wrote:
> Can someone out there check this quickly?
>
> In radeon.h in the 2d driver, the size of the radeon mmio area is
> defined as 0x8 - however, on my r200 at least, /proc/pci shows the
> area as being 1/8th that size:
>
> Bus 1, device 0, function 0:
> ... (omitted
On July 16, 2002 04:15 pm, you wrote:
> Every so often (for example after 1hr of gameplay) a glx program like RTCW
> or WINE running SOF2 freezes... now, Only the program however, X is fine.
> However it freezes my mouse and kdb... if I telnet in and kill the
> offending process things are almost
Every so often (for example after 1hr of gameplay) a glx program like RTCW or
WINE running SOF2 freezes... now, Only the program however, X is fine.
However it freezes my mouse and kdb... if I telnet in and kill the offending
process things are almost back to normal except my mouse accel isn't
ckly?
> In radeon.h in the 2d driver, the size of the radeon mmio area is defined as
> 0x8 - however, on my r200 at least, /proc/pci shows the area as being 1/8th
> that size:
>Bus 1, device 0, function 0:
> ... (omitted) ...
>Non-prefetchable 32 bit memory at 0xff5f000
Can someone out there check this quickly?
In radeon.h in the 2d driver, the size of the radeon mmio area is defined as
0x8 - however, on my r200 at least, /proc/pci shows the area as being
1/8th that size:
Bus 1, device 0, function 0:
... (omitted) ...
Non-prefetchable 32 bit
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,
> > it _eliminates_ some saves/restores necessary for unfilled polygons with
> > hardware flat-s
> 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,
> it _eliminates_ some saves/restores necessary for unfilled polygons with
> hardware flat-shading.
>
> Actually, I think the problem is larg
On Tue, 16 Jul 2002, José Fonseca wrote:
> On Tue, Jul 16, 2002 at 11:54:02AM -0400, Leif Delgass wrote:
> > On Wed, 10 Jul 2002, Allen Barnett wrote:
> >
> > > 2. clipping.c: In this program, a cube is drawn using a flat shaded quad
> > > strip with different colors for each pair of vertices.
Marc Poulhiès wrote:
> I have been playing tribes2 without a problem exept that the sound gets
> more and more noise with higher resolution... 800x600 is fine, 1024x768
> sounds creepy and 1280x1024 is just horrible. I have this probleme
> specialy in tribes2 menu. I read in the README.r200 in the
I have been playing tribes2 without a problem exept that the sound gets
more and more noise with higher resolution... 800x600 is fine, 1024x768
sounds creepy and 1280x1024 is just horrible. I have this probleme
specialy in tribes2 menu. I read in the README.r200 in the directory
where the bleeding
On Tue, Jul 16, 2002 at 11:54:02AM -0400, Leif Delgass wrote:
> On Wed, 10 Jul 2002, Allen Barnett wrote:
>
> > 2. clipping.c: In this program, a cube is drawn using a flat shaded quad
> > strip with different colors for each pair of vertices. If a face of the cube
> > is clipped by an edge of
I'm CC'ing to dri-devel as well to get a broaded audience.
On Tue, Jul 16, 2002 at 05:28:37PM +0200, dylan wrote:
> Good plan, The DRM module is not happy and throws a bit of a fit.
>
> Here is a small snippet showing the exact response, how would I go
> about upgrading the drm module or would
On Wed, 10 Jul 2002, Allen Barnett wrote:
> 2. clipping.c: In this program, a cube is drawn using a flat shaded quad
> strip with different colors for each pair of vertices. If a face of the cube
> is clipped by an edge of the X window, then the triangles which the quad is
> decomposed into ar
Thanks for the snapshots Leif. For what you've shown me it seems that
the problem lives in TAG(interp) of mach64_native_vbtmp.h.
Unfortunetaly I haven't been able to do much testing yet, because after
updating my local CVS tree with the recent changes I was forced to recompile
the whole tree aga
On Tue, 2002-07-16 at 07:41, Eric Anholt wrote:
> On Mon, 2002-07-15 at 23:15, Mike Mestnik wrote:
>
> > 2. There is no suported flag, so DRM_SUP can go.
>
> Well, it removes the ability for a platform to simply not have
> __REALLY_HAVE_SG (for example, this was the case on FreeBSD for quite a
>
44 matches
Mail list logo
