On Fri, 2004-01-16 at 18:01, Roland Scheidegger wrote:
> Roland Scheidegger wrote:
> > Ian Romanick wrote:
> >
> >> http://marc.theaimsgroup.com/?l=dri-devel&m=105862837814769&w=2
>
> Seems to be quite complicated. Though wouldn't it be a better idea to
> figure out why it doesn't work in the fi
Ian Romanick wrote:
Seems to be quite complicated. Though wouldn't it be a better idea to
figure out why it doesn't work in the first place? R200/RV250 should
support this, but apparently for some reason it doesn't work.
According to r200_reg.h, the chip should also be able to handle
ARB_point_
Roland Scheidegger wrote:
Roland Scheidegger wrote:
Ian Romanick wrote:
Right. Could you try it again with this patch. You may need some
changes to get it to apply. If this works, can somebody commit it?
http://marc.theaimsgroup.com/?l=dri-devel&m=105862837814769&w=2
This patch is only for ra
Roland Scheidegger wrote:
Ian Romanick wrote:
Roland Scheidegger wrote:
pointblast: (both with hardware tcl and without) the points are
almost invisible. IIRC this was already mentioned some time ago to
be because all points are drawn with size 1 only.
Right. Could you try it again with this p
Ian Romanick wrote:
Roland Scheidegger wrote:
pointblast: (both with hardware tcl and without) the points are
almost invisible. IIRC this was already mentioned some time ago to
be because all points are drawn with size 1 only.
Right. Could you try it again with this patch. You may need some
c
Roland Scheidegger wrote:
pointblast:
(both with hardware tcl and without) the points are almost
invisible. IIRC this was already mentioned some time ago to be because
all points are drawn with size 1 only.
Right. Could you try it again with this patch. You may need some
changes to get it to ap
On Wed, 2004-01-14 at 16:10, Brian Paul wrote:
> Roland Scheidegger wrote:
> >
> > I've just seen there are some fixes very recently in the drm module for
> > the cubic offsets which I've missed before (as I don't update the drm
> > module every time I'll compile the 3d driver).
> > Unfortunately
Roland Scheidegger wrote:
Brian Paul wrote:
cubemap: with hardware tcl inner sphere looks correct, outer cube has
only blue face, the others are missing, and texture is more fuzzy
(might be just a different lod bias?) compared to software mesa.
tcl_mode=0 is even worse: inner sphere everything
Am 2004.01.14 00:43:07 +0100 schrieb(en) Roland Scheidegger:
> I've just had too much spare time and though it would be interesting to
> see which mesa demos/tests have problems (lighting or otherwise), so
> here are the results of all tests which did not run correctly (of course
> quite a few t
Dieter Nützel wrote:
Dieter Nützel wrote:
stex3d:
the 3d texture fallback seems to be very slow. software mesa
seems to run about 2-3 times faster than hardware acceleration using the
fallback.
Not sure about that, but the TexCoord3 issue would also apply here.
Can you verify the "clipping bug" (w
Am Mittwoch, 14. Januar 2004 03:19 schrieb Roland Scheidegger:
> Dieter Nützel wrote:
> >>>stex3d:
> >>>the 3d texture fallback seems to be very slow. software mesa
> >>>seems to run about 2-3 times faster than hardware acceleration using the
> >>>fallback.
> >>
> >>Not sure about that, but the Tex
--- Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> Dieter Nützel wrote:
[snip]
>
> Roland
> btw what's wrong with my message headers? I'm always getting "Your
> message to Dri-devel awaits moderator approval" because of "Message
> has
> a suspicious header".
>
>
I get the same thing from ti
Am Mittwoch, 14. Januar 2004 03:24 schrieb Roland Scheidegger:
> Dieter Nützel wrote:
> >>cubemap:
> >>with hardware tcl inner sphere looks correct, outer cube has
> >>only blue face, the others are missing, and texture is more fuzzy (might
> >>be just a different lod bias?) compared to software me
On Wed, 2004-01-14 at 03:24, Roland Scheidegger wrote:
> Dieter NÃtzel wrote:
> >
> > See "Re: [Dri-devel] [trunk] r200 current CVS", too.
[...]
> Ok with this patch apps which use texturing work again :-)
BTW I've committed Andreas' cubic texture offsets initialisation fix.
> (glxgears still
Dieter Nützel wrote:
This also
seemed to cause a drop in glxgears performance (one of the few apps
which don't use texturing...) by a factor of 10 or so (but yes, it is
using hardware rendering).
No, not seen here (r200) without and with Andreas fix.
progs/demos>
progs/demos> 9899 frames in 5.
Dieter Nützel wrote:
cubemap:
with hardware tcl inner sphere looks correct, outer cube has
only blue face, the others are missing, and texture is more fuzzy (might
be just a different lod bias?) compared to software mesa.
tcl_mode=0 is even worse: inner sphere everything is only blue/white,
outer c
Am Mittwoch, 14. Januar 2004 02:56 schrieb Roland Scheidegger:
> Brian Paul wrote:
> >> cubemap: with hardware tcl inner sphere looks correct, outer cube
> >> has only blue face, the others are missing, and texture is more
> >> fuzzy (might be just a different lod bias?) compared to software
> >> m
Dieter Nützel wrote:
stex3d:
the 3d texture fallback seems to be very slow. software mesa
seems to run about 2-3 times faster than hardware acceleration using the
fallback.
Not sure about that, but the TexCoord3 issue would also apply here.
Can you verify the "clipping bug" (with r200) when you m
Brian Paul wrote:
cubemap: with hardware tcl inner sphere looks correct, outer cube
has only blue face, the others are missing, and texture is more
fuzzy (might be just a different lod bias?) compared to software
mesa. tcl_mode=0 is even worse: inner sphere everything is only
blue/white, outer
Am Mittwoch, 14. Januar 2004 01:09 schrieb Brian Paul:
> Roland Scheidegger wrote:
> > I've just had too much spare time and though it would be interesting to
> > see which mesa demos/tests have problems (lighting or otherwise), so
> > here are the results of all tests which did not run correctly (
Am Mittwoch, 14. Januar 2004 00:43 schrieb Roland Scheidegger:
> I've just had too much spare time and though it would be interesting to
> see which mesa demos/tests have problems (lighting or otherwise), so
> here are the results of all tests which did not run correctly (of course
> quite a few te
Roland Scheidegger wrote:
I've just had too much spare time and though it would be interesting to
see which mesa demos/tests have problems (lighting or otherwise), so
here are the results of all tests which did not run correctly (of course
quite a few tests wouldn't run at all due to missing arb
I've just had too much spare time and though it would be interesting to
see which mesa demos/tests have problems (lighting or otherwise), so
here are the results of all tests which did not run correctly (of course
quite a few tests wouldn't run at all due to missing arb_fp, arb_vp or
whatever e
23 matches
Mail list logo
