On Mon, 14 Feb 2005 16:13:18 +0100, Jerome Glisse <[EMAIL PROTECTED]> wrote:
> On Mon, 14 Feb 2005 10:02:07 -0500 (EST), Vladimir Dergachev
> <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Mon, 14 Feb 2005, Jerome Glisse wrote:
> >
> > >> On Mon, 14 Feb 2005 17:17:05 +1100, Paul Mackerras <[EMAIL PROTEC
Peter Zubaj wrote:
For me looks like:
If you uncoment r300 support in
int radeon_do_cp_idle(drm_radeon_private_t * dev_priv)
and in
static void radeon_cp_dispatch_swap(drm_device_t * dev)
x will work ok (no more locks or crash), but no 3d.
Peter Zubaj
Vsetko o
I'm just looking through the docs this evening and I noticed the
TXOFFSET_0 register has endian swapping for textures in hardware,
This allowed me to remove some swizzling in my own application along with
client side texturing... (i.e. more speed less processing..)
I'm thinking about how these c
Dave Airlie wrote:
I'm just looking through the docs this evening and I noticed the
TXOFFSET_0 register has endian swapping for textures in hardware,
This allowed me to remove some swizzling in my own application along with
client side texturing... (i.e. more speed less processing..)
I'm thinking a
> >
> > I'm thinking about how these could be used in Mesa drivers? would I be
> > correct in thinking the fallbacks would mess up as the Mesa copy of the
> > texture wouldn't be the same as what the card would be using?
>
> I'm not sure that the fallbacks in their current form ever actually read f
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2529
--- Additional Comments From [EMAIL PROTECTED] 2005-02-15 05:22 ---
Unfor
On Tue, 2005-02-15 at 11:47 +, Dave Airlie wrote:
> > >
> > > I'm thinking about how these could be used in Mesa drivers? would I be
> > > correct in thinking the fallbacks would mess up as the Mesa copy of the
> > > texture wouldn't be the same as what the card would be using?
> >
> > I'm not
Well, X only locks up for me when using 3D. If I wanted that trade-off,
I'd just disable DRI :-)
Adam
Hi Adam,
I forget - did I ask you to try immediate mode ? You can switch to it
inside r300/r300_render.c, search for #if
best
Vladimir Dergac
{R300_EASY_TX_FORMAT(Y, Y, Y, X, Y8X8), 0},
{R300_EASY_TX_FORMAT(Y, Y, X, Y, Y8X8), 0},
But testing if the result is good is better :)
I commited a patch for big endian, i will do a test prog
so we can test texture format on x86 & ppc.
Great !
Btw, does anyone know whether we are obligated to u
On Tue, 2005-02-15 at 02:36 -0500, Vladimir Dergachev wrote:
>
> AFAIK, the lockups are due to interference between 2d packets from Xserver
> and 3d packets from the driver. Somehow mouse movement provokes it,
> possibly when the cursor shape changes on crossing window boundaries..
>
> It is n
On Tue, 15 Feb 2005, Michel [ISO-8859-1] Dänzer wrote:
On Tue, 2005-02-15 at 02:36 -0500, Vladimir Dergachev wrote:
AFAIK, the lockups are due to interference between 2d packets from Xserver
and 3d packets from the driver. Somehow mouse movement provokes it,
possibly when the cursor shape changes
On Tue, 2005-02-15 at 11:36 -0500, Vladimir Dergachev wrote:
>
> On Tue, 15 Feb 2005, Michel [ISO-8859-1] Dnzer wrote:
>
> > On Tue, 2005-02-15 at 02:36 -0500, Vladimir Dergachev wrote:
> >>
> >> AFAIK, the lockups are due to interference between 2d packets from Xserver
> >> and 3d packets from t
Have you tried idling the engine before uploading the cursor data?
I haven't played with that part of 2d driver, but shouldn't it do this
already as all ATI cards are touchy about framebuffer access while
the graphics engine is busy ?
It arguably should, but it doesn't AFAICT.
That's what I thought
On Tue, 2005-02-15 at 12:08 -0500, Vladimir Dergachev wrote:
> >>> Have you tried idling the engine before uploading the cursor data?
> >>
> >> I haven't played with that part of 2d driver, but shouldn't it do this
> >> already as all ATI cards are touchy about framebuffer access while
> >> the gra
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2529
--- Additional Comments From [EMAIL PROTECTED] 2005-02-15 10:33 ---
This
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2529
--- Additional Comments From [EMAIL PROTECTED] 2005-02-15 12:07 ---
(In r
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
>> Try removing the RADEONSetFBLocation() call in
> RADEONAdjustFrame().
> That's a messup which I unfortunately discovered
> only too late for 6.8.2.
Ouch. Nope, celestia still locks up in a "WriteDRM"
system call. I am sticking with 6.8.1 for now.
On Mon, 14 Feb 2005 14:18:26 -0600, Ryan Underwood <[EMAIL PROTECTED]> wrote:
> I've been looking at Xgl and mesa-solo recently and my interest has been
> piqued. I have been hacking on the mga drivers for a while now. What
> do we need to do to the mga framebuffer, DRM, DRI, and/or XAA drivers i
On Tue, 15 Feb 2005 17:59:00 -0500, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On Mon, 14 Feb 2005 14:18:26 -0600, Ryan Underwood <[EMAIL PROTECTED]> wrote:
> > I've been looking at Xgl and mesa-solo recently and my interest has been
> > piqued. I have been hacking on the mga drivers for a while now.
Chris Rankin wrote:
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
Try removing the RADEONSetFBLocation() call in
RADEONAdjustFrame().
That's a messup which I unfortunately discovered
only too late for 6.8.2.
Ouch. Nope, celestia still locks up in a "WriteDRM"
system call. I am sticking with 6.8.1
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> Try removing the RADEONSetFBLocation() call in
> RADEONAdjustFrame().
By the power of my serial console, here is what gdb
says about my crazy celestia-1.3.2 process:
0xe410 in __kernel_vsyscall ()
(gdb) where
#0 0xe410 in __kernel_vsyscall
I updated to the latest r300 code in cvs tonight in an effort to do some
testing and noticed an immediate regression. glxgears locked up almost
immediately, and neverputt locked up within a few minutes.
I wanted to test each change, step-by-step, from "jump_and_click" to
today but, unfortunate
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2529
--- Additional Comments From [EMAIL PROTECTED] 2005-02-15 20:40 ---
The G
On Sunday 13 February 2005 16:30, Felix K=FChling wrote:
>
> I took another look at your lspci-output. It's a PCI
> card, right? I saw vertex corruption with PCI-DMA on my
> Savage4 once. Maybe this isn't working reliably. Does it
> help to set enable_vdma to false (in driconf or the
> environment)
On Tue, 15 Feb 2005, Adam K Kirchhoff wrote:
I updated to the latest r300 code in cvs tonight in an effort to do some
testing and noticed an immediate regression. glxgears locked up almost
immediately, and neverputt locked up within a few minutes.
Even with immediate mode rendering ?
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2529
--- Additional Comments From [EMAIL PROTECTED] 2005-02-15 20:59 ---
It mi
On Wed, 16 Feb 2005 05:51:25 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Sunday 13 February 2005 16:30, Felix K=FChling wrote:
> >
> > I took another look at your lspci-output. It's a PCI
> > card, right? I saw vertex corruption with PCI-DMA on my
> > Savage4 once. Maybe this isn't wor
27 matches
Mail list logo
