Aapo Tahkola wrote:
Aapo Tahkola wrote:
I think the dummy only worked for you. It didn't help me.
this also fixed software fallback for me.
just to be sure:
when you run arbvptorus (unmodified) do you get the texobj=NULL warning?
They dont show up today and they arent in yesterdays logs.
Not even
On Tue, 1 Mar 2005, Benjamin Herrenschmidt wrote:
On Mon, 2005-02-28 at 15:09 -0500, Michel Dänzer wrote:
On Mon, 2005-02-28 at 10:19 -0500, Alex Deucher wrote:
I think long term though, a better solution would be to get rid of
mergedfb and handle each head separately but just change the 2d/3d
eng
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=2625
[EMAIL PROTECTED] changed:
What|Removed |Added
--
On Tue, 01 Mar 2005 01:09:28 -0500, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-03-01 at 17:02 +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2005-02-28 at 15:09 -0500, Michel Dänzer wrote:
> > > On Mon, 2005-02-28 at 10:19 -0500, Alex Deucher wrote:
> > > >
> > > > I think long term
>
> Bad news:
> That extra instruction causes texobj=NULL and therefore texture
> corruption.
Looks like it indeed.
This is caused by incorrectly enabling texture units based on inputs.
Something like
if(ctx->Texture.Unit[i].Enabled == 0)
continue;
in r300_
Dieter NÃtzel wrote:
Am Mittwoch, 16. Februar 2005 21:27 schrieb Dieter NÃtzel:
Any change that someone look into this?
Ian, it seems that's related to your new SSE/MMX code.
Thanks,
Dieter
Move window 'out' to the left.
NO sigfault with MESA_NO_SSE and MESA_NO_MMX.
With MMX:
#0 0x406a92b
Hi,
I'm new to DRI development but am interested in helping with the r300
driver. I am trying to get the driver working with my Radeon 9550 and
I have glxinfo reporting that direct rendering is enabled and the
OpenGL renderer string is "Mesa DRI R300 20040924 AGP 4x
x86/MMX+/3DNow!+/SSE NO-TCL",
Am Dienstag, 1. März 2005 19:46 schrieb Roland Scheidegger:
> Dieter Nützel wrote:
> >>Looking a bit at this, this seems to be caused because the number of
> >>pixels to read can be less than zero after CLIPSPAN (don't know if
> >>that's a bug in itself or not).
> >
> > That was my first thought, t
DRM CVS
Thanks,
Dieter
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.co
On Tue, 1 Mar 2005 [EMAIL PROTECTED] wrote:
Hi,
I'm new to DRI development but am interested in helping with the r300
driver. I am trying to get the driver working with my Radeon 9550 and
I have glxinfo reporting that direct rendering is enabled and the
OpenGL renderer string is "Mesa DRI R300 20
Hi all,
Since there were no objections to updating to latest DRM from
freedesktop.org, I will try to make the upgrade now.
* Please do not commit anything into r300_driver/drm - I will
post the message when I am done.
* The latest code before the upgrade has been tagged as
I finished the update. I suggest checking out a clean copy of r300_driver
and trying linux-core.
Please e-mail me if anything broke, or if I forgot to check in something.
From now on we can use the following command:
cvs -z3 diff -u -r orig
to obtain diffs between our version of DRM and orig
For the r128 driver both the fbdev and drm drivers have implemented
waitforVBlank and they both play with the interrupt registers. I can
only assume that no one has ever tried to use them at the same time.
In the radeon case the DRM driver has implemented waitforVBlank and
the fbdev driver has not.
On Wed, Mar 02, 2005 at 06:10:14PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-02 at 00:50 -0500, Jon Smirl wrote:
> > For the r128 driver both the fbdev and drm drivers have implemented
> > waitforVBlank and they both play with the interrupt registers. I can
> > only assume that no one
14 matches
Mail list logo
