On Thu, May 02, 2002 at 03:38:02AM +0200, Smitty wrote:
> Howzit Ian?
>
> First off, dankie.
>
>
> Noted, used, and added a few mechanisms to deal with:
> I think
> Nvidia proprietary
>
> > Texture
> > ===
> > Cache -- Automatically supported by the hardware.
> Not
Howzit Ian?
First off, dankie.
Noted, used, and added a few mechanisms to deal with:
I think
Nvidia proprietary
> Texture
> ===
> Cache -- Automatically supported by the hardware.
Not according to Michael Ntlworld, and he backed it up.
Oh and I won't post such a ma
Hi
> Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in
> CVS now. Just update and rebuild and install the kernel module. This is
> not related to your original problem though, I'm not sure what would be
> causing a lockup on vt switches if no GL contexts are running.
Hello!
I've finally had a chance to upgrade to XFree86 4.2.0, and am trying out
the bleeding edge builds for mach64. :)
Quick version: it doesn't work.
Long version: I think I have an AGP problem.
glxinfo reports that direct rendering is off.
the mach64 kernel driver compiled and is loaded,
> Well, it should work on both cases, but the patch was meant to test
> with MACH_USE_DMA set to 0. Again, it should work with set as 1
> (otherwise means a regression), but we wanted that it also worked with
> set as 0.
I have just changed the MACH_USE_DMA to 0 and recompiled the kernel
modu
On 2002.05.01 23:11 Peter Andersson wrote:
> Leif Delgass wrote:
>
>> On Wed, 1 May 2002, Peter Andersson wrote:
>>
>>> I have compiled the new kernel drivers and get the following error
>>> when trying to run glxgears:
>>>
>>> Error flushing vertex buffer: return = -16
>>>
>>> Peter
>>>
>>
Leif Delgass wrote:
>On Wed, 1 May 2002, Peter Andersson wrote:
>
>>I have compiled the new kernel drivers and get the following error when
>>trying to run glxgears:
>>
>>Error flushing vertex buffer: return = -16
>>
>>Peter
>>
>
>That means the engine is locking up. Either wait_for_idle fails
On Wed, 1 May 2002, Frank C. Earl wrote:
> > The part which is missing is more or less what we have in the
> > mach64-0-0-4-branch, except that the state update is still being made with
> > MMIO. So either we add the remaining parts to mach64-0-0-3-branch or we
> > bring Frank's changes to mach64
On Wed, 1 May 2002, Peter Andersson wrote:
> I have compiled the new kernel drivers and get the following error when
> trying to run glxgears:
>
> Error flushing vertex buffer: return = -16
>
> Peter
That means the engine is locking up. Either wait_for_idle fails (DMA)
or wait_for_fifo fa
I have compiled the new kernel drivers and get the following error when
trying to run glxgears:
Error flushing vertex buffer: return = -16
Peter
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the
On 1 May 2002, Sergey V. Udaltsov wrote:
> Hi
>
> > Do you use some framebuffer device?
> To the best of my knowledge - no.
>
> > You can start to give us the last lines of /var/log/messages, as I think
> > that there should be a kernel oops in there. The XFree86.log may be
> > interesting to
Alex,
On 2002.05.01 20:50 alexander kern wrote:
> Hello,
>
> I have trayed with DRI (mach64 driver from 04.30.2002) and cannot see any
> difference in perfomance. Without install of DRI I had about ~170 FPS by
> gears, and glxinfo says "DRI is on"(?-) astonishment). With DRI and
> libGL.so
> lin
Hi
> Do you use some framebuffer device?
To the best of my knowledge - no.
> You can start to give us the last lines of /var/log/messages, as I think
> that there should be a kernel oops in there. The XFree86.log may be
> interesting too.
YESS! There is OOPS. See attached.
Cheers,
Sergey
M
Hello,
I have trayed with DRI (mach64 driver from 04.30.2002) and cannot see any
difference in perfomance. Without install of DRI I had about ~170 FPS by
gears, and glxinfo says "DRI is on"(?-) astonishment). With DRI and libGL.so
linked to mesa, I had ~175 FPS and glxinfo says "DRI is on". (O
On Wednesday 01 May 2002 03:58 am, JosX Fonseca wrote:
> Frank just commited a set of changes to the mach64-0-0-3-dma-branch. Is in
> own words:
>
> "Most of the first cut of the DMA code. It's got most of the
> dispatch
> architecture in place (Lacks actual DMA submission (The easy part,
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
On Mon, Apr 29, 2002 at 04:40:21AM +0200, Smitty wrote:
Added:
Pixel shader
Programmable texture blending modes - Yes. EXT_texture_env_combine is
supported, and ARB_texture_env_combine
and ARB_te
On Wed, 1 May 2002, Peter Andersson wrote:
> Sorry about the lateness of my reply but i have been away over night and
> didn´t get this mail until just recently. The patch fails when patching
> mach64_state.c. It exits with "HUNK #2 FAILED at 535" and i am not
> comfortable with applying the c
> I attached a complete diff that should do the right thing. I believe
> this is the only way to do this in a portable fashion, even if results
> in some redundant work being done on bigendian machines. I also
> avoided to increment the pointer inside the macros, just in case the
> le32_to_cpu
On 2002.05.01 16:18 Leif Delgass wrote:
> One thing I realized concerning blits:
> the utah driver uses the host_data[0-15] registers to do blits which
> treats blits as a GUI-master operation. This means it works with
> pseudo-DMA. I think the better way to do it is to use the system bus
I realized what was causing the oops when trying to access the buffer
private struct in the PCI path. The DRM template code for addbufs_pci
does __not__ allocate memory for a private structure for the buffers,
whereas the template code for addbufs_agp and addbufs_sg does.
I'm not sure if we'l
On Wed, 1 May 2002, José Fonseca wrote:
> Frank just commited a set of changes to the mach64-0-0-3-dma-branch. Is in
> own words:
>
> "Most of the first cut of the DMA code. It's got most of the
> dispatch
> architecture in place (Lacks actual DMA submission (The easy part,
> really...
Bamboo
Flooring Limited
;
The most
environmentally
friendly, hardest wearing hard wood flooring is now available at the best
prices!
Save
almost £5000 on a 1500 sq. meter delivery
These
bamboo products are mad
Frank just commited a set of changes to the mach64-0-0-3-dma-branch. Is in
own words:
"Most of the first cut of the DMA code. It's got most of the
dispatch
architecture in place (Lacks actual DMA submission (The easy part,
really...))
so it's not done yet, but I promised people that d
24 matches
Mail list logo
