Hey,
From what I can tell, it accesses 16mb. "Aperature Base can be
allocated anywhere in the shaded region and is aligned to a multiple of
16MB" This comes from page 17. Congratulations on your work on the
driver, and thanks.
Carl Busjahn
Gareth Hughes wrote:
> Leif Delgass wrote:
>
>>
Just a warning, with the direct register writes enabled in
mach64_dma_dispatch_clear (in mach64_state.c), switching to a virtual
terminal and back to X causes my box to hang hard -- I can't ssh in and
Alt-SysRq doesn't work.
--
Leif Delgass
___
Dri-d
Leif Delgass wrote:
> Great work! I'll check this out soon.
>
> Once we get DMA working for the 3D operations, I guess the next task is to
> get the 2D acceleration routines synchronizing with the 3D ones so we can
> reenable XAA, right? Also, it looks as if the AGP setup has not been
> finish
On Fri, 19 Oct 2001 17:24, Leif Delgass wrote:
> Great work! I'll check this out soon.
>
> Once we get DMA working for the 3D operations, I guess the next task is to
> get the 2D acceleration routines synchronizing with the 3D ones so we can
> reenable XAA, right? Also, it looks as if the AGP se
Based on the r128 and radeon code, here's a diff for atidri.c that
initializes the AGP registers and enables bus mastering in PCI config
space (in case it wasn't done on boot). Also, I tried setting GUI_CNTL to
0x0001 and the dma test worked for me also!
--- atidri.orig.c Fri Oct 19 19
Great work! I'll check this out soon.
Once we get DMA working for the 3D operations, I guess the next task is to
get the 2D acceleration routines synchronizing with the 3D ones so we can
reenable XAA, right? Also, it looks as if the AGP setup has not been
finished yet. At this point, atidri.c
Hello again.
Well, after some tests, it seems that the problem was caused by the FIFO
size. This was one of the differences between running the little module
(ati_mach64gui.o) under or without X (this is because in the 2D driver,
GUI_CNTL is set to zero when pATI->Chip >= ATI_CHIP_264VT4, in
Manuel Teira wrote:
>
> [snip]
>
> Now, WITHOUT STARTING X, test the GUI DMA transfer, for example, typing:
> # dd if=/dev/atidma of=atiout.dat bs=512 count=1
>
> It worked, the module dumped:
> (Before DMA Transfer) PAT_REG0 = 0x
> (After DMA Transfer) PAT_REG0 = 0x
Great
Well. Now, I trust that the problem is in X initialization.
I've modified the driver that R.C. gently sent us. It didn't worked for me,
because of the IRQ issues I posted yesterday. As the GUI DMA test doesn't
need IRQs, I've taken out that initialization and modified the device_read
function
On Fri, 19 Oct 2001, Malte Cornils wrote:
> Yep, I do have another question though. Is it necessary to specify
> mach64 manually in xc/config/cf/host.def? If so, the patch should
> probably modify this file in that regard, too.
That's not necessary, the mach64 driver is part of the "ati" (2D) dr
[EMAIL PROTECTED] wrote:
> > /usr/bin/ld: cannot find -lXau
> [...]
> Perhaps the fastest solution is copying the /usr/X11R6 to the
> /usr/X11R6-DRI directory to avoid this compilation problems. Then, the
> installation will overwrite the important stuff.
I'm currently trying to compile this, too
Hi,
> well, look at mplayer
>
> but some said there are .. BGR related problems ..
I've traced down the G400/G550-related problems:
problem #1:
15bpp-like texture:
change internal_format from GL_RGBA8 to GL_RGB8, it solves this.
i think if alpha is used, then g400 driver uses 4:4:4:4 pixel fo
Liam Wilks writes:
> Could anybody help me with this problem? DRI doesn't seem to want to
> compile from CVS. I am running Redhat 7.1, with kernel 2.4.5 patched for
> Win4Lin, and XFree86 4.10.
>
> I have an ATI Rage Mobility P/M Graphics Card, which is a Mach 64 based
> card. I downloaded the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 18 October 2001 14:50, Michael Zayats wrote:
>
> Do you know whether 2D textures might be used as a surface to draw video
> on? Is DMA path of memory -> texture implemented in i810 driver? (4.1.0)
>
> what do you think of this path at all?
14 matches
Mail list logo
