On Tue, 8 Feb 2005, Michel [ISO-8859-1] Dänzer wrote:
> On Mon, 2005-02-07 at 13:40 +0100, Geller Sandor wrote:
> >
> > Is there any way I can help to track down the problem(s)? My machine
> > doesn't have network connection, so I can use only scripts which run in
> > the background. With expect a
Stephane Marchesin wrote:
Hi,
Attached is a straight port of Eric's fix for the drm race to non-core drm.
Committed.
Keith
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
On Thu, 10 Feb 2005 16:16:12 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> Hi !
>
> An interesting issue with current X.org CVS and current Linux bk is that
> on r300, the DRI module now loads, and 2D is broken. It looks like an
> endian issue (like pixels are horizontally flipped), I
Am Donnerstag, den 10.02.2005, 07:21 +0100 schrieb [EMAIL PROTECTED]:
> On Monday 07 February 2005 15:33, Felix K=FChling wrote:
> > Am Montag, den 07.02.2005, 15:12 +0100 schrieb=20
> [EMAIL PROTECTED]:
> > > Hardware:
> > >
> > > Toshiba Libretto L2 Tm5600 with:
> > >
> > > :00:04.0 VGA compa
Since 2 people have asked for it, here are some quick numbers for r200
dri vs. fglrx.
r200 dri is using 45MB local tex heap (I believe fglrx reseverves pretty
much anything for textures too, so that's only fair...). btw fglrx
certainly has made some progress, what I noticed is at least 2d
subje
Roland Scheidegger wrote:
Any ideas what's causing this? Maybe fglrx reconfigures the card's
caches or something like that? It would be nice if we could get that
additional 10-15% performance, especially if it is as simple as writing
a single register...
My guess would be that the fglrx driver u
On Thu, 10 Feb 2005 17:18:44 +0100, Roland Scheidegger
<[EMAIL PROTECTED]> wrote:
> Since 2 people have asked for it, here are some quick numbers for r200
> dri vs. fglrx.
> r200 dri is using 45MB local tex heap (I believe fglrx reseverves pretty
> much anything for textures too, so that's only fai
Ian Romanick wrote:
Roland Scheidegger wrote:
Any ideas what's causing this? Maybe fglrx reconfigures the card's
caches or something like that? It would be nice if we could get that
additional 10-15% performance, especially if it is as simple as
writing a single register...
My guess would be th
Roland Scheidegger wrote:
Ian Romanick wrote:
Roland Scheidegger wrote:
Any ideas what's causing this? Maybe fglrx reconfigures the card's
caches or something like that? It would be nice if we could get that
additional 10-15% performance, especially if it is as simple as
writing a single registe
Roland Scheidegger wrote:
Ian Romanick wrote:
Roland Scheidegger wrote:
Any ideas what's causing this? Maybe fglrx reconfigures the card's
caches or something like that? It would be nice if we could get that
additional 10-15% performance, especially if it is as simple as
writing a single registe
On Thursday 10 February 2005 11:18, Roland Scheidegger wrote:
> r200 dri uses xorg cvs head, with dri driver from Mesa cvs head, with
> color tiling, texture tiling, hyperz and whatever else I could find
> boosting performance :-).
> fglrx uses XFree86 4.3.99.902 (from suse 9.1), with stock configu
Alex Deucher wrote:
And now the really interesting thing:
The results marked with 1) are obtained BEFORE running fglrx, the result
marked with 2) AFTER running fglrx, i.e. when I did not reboot between
running the fglrx driver and the radeon driver (which in the past lead
to lockups, but driver swi
Adam Jackson wrote:
On Thursday 10 February 2005 11:18, Roland Scheidegger wrote:
r200 dri uses xorg cvs head, with dri driver from Mesa cvs head, with
color tiling, texture tiling, hyperz and whatever else I could find
boosting performance :-).
fglrx uses XFree86 4.3.99.902 (from suse 9.1), with s
r100-readpixels-3.patch (Stephane)
r200_pntparam_1.diff (Roland)
I'm ran with both.
Should they merged?
BTW "readpix" sigfault is still there. (with and without both patches)
X.org CVS do NOT show this bug.
SunWave1 progs/demos# ./readpix
GL_VERSION = 1.3 Mesa 6.3
GL_RENDERER = Mesa DRI R200 20
Am Mittwoch, den 09.02.2005, 22:12 +0100 schrieb Felix Kühling:
> Am Mittwoch, den 09.02.2005, 20:58 +0100 schrieb Roland Scheidegger:
[snip]
> > Performance with gart texturing, even in 4x mode, takes a big hit
> > (almost 50%).
> > I was not really able to get consistent performance results wh
Dieter NÃtzel wrote:
r100-readpixels-3.patch (Stephane)
r200_pntparam_1.diff (Roland)
I'm ran with both.
Should they merged?
I surely hope to get my readpixels patch merged. However, I found a
serious flaw in it (not related to the readpixe segfault) which I have
to fix before this happens.
Step
Hello,
I've attached a patch with a port of the r200 vertex buffer code for the
r300 driver.
The performance of the vertex buffer codepath is now roughly the same as the
immediate path, and tuxracer now seems to be rendered almost correctly.
Vladimir, I haven't found a way that I can directly cal
On Thursday 10 February 2005 12:53, Roland Scheidegger wrote:
> Adam Jackson wrote:
> > On Thursday 10 February 2005 11:18, Roland Scheidegger wrote:
> >>r200 dri uses xorg cvs head, with dri driver from Mesa cvs head, with
> >>color tiling, texture tiling, hyperz and whatever else I could find
> >
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=1648
[EMAIL PROTECTED] changed:
What|Removed |Added
--
Stephane Marchesin wrote:
Dieter NÃtzel wrote:
r100-readpixels-3.patch (Stephane)
r200_pntparam_1.diff (Roland)
I'm ran with both.
Should they merged?
I surely hope to get my readpixels patch merged. However, I found a
serious flaw in it (not related to the readpixe segfault) which I have
to fix
I haven't looked at the texture heap management code, but one simple
idea for heap management would be to cascade the on-board heap to the
AGP one. How does the current algorithm work? Does an algorithm like
the one below have merit? It should sort the hot textures on-board,
and single use textures
Adam Jackson wrote:
On Thursday 10 February 2005 12:53, Roland Scheidegger wrote:
Adam Jackson wrote:
On Thursday 10 February 2005 11:18, Roland Scheidegger wrote:
r200 dri uses xorg cvs head, with dri driver from Mesa cvs head, with
color tiling, texture tiling, hyperz and whatever else I could fi
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=2241
--- Additional Comments From [EMAIL PROTECTED] 2005-02-10 14:06 ---
I hav
Am Donnerstag, den 10.02.2005, 15:31 -0500 schrieb Jon Smirl:
> I haven't looked at the texture heap management code, but one simple
> idea for heap management would be to cascade the on-board heap to the
> AGP one. How does the current algorithm work? Does an algorithm like
> the one below have me
On Thu, 10 Feb 2005 23:13:30 +0100, Felix Kühling <[EMAIL PROTECTED]> wrote:
> This means you copy a texture when you don't know if or when you're
> going to need it again. So the move of the texture may just be a waste
> of time. It would be better to just kick the texture and upload it again
> la
On Thu, 10 Feb 2005 23:13:30 +0100, Felix Kühling <[EMAIL PROTECTED]> wrote:
> This scheme would give good results with movie players that need fast
> texture uploads and typically use each texture exactly once. It would
Movie players aren't even close to being texture bandwidth bound. The
demote
Am Donnerstag, den 10.02.2005, 17:40 -0500 schrieb Jon Smirl:
> On Thu, 10 Feb 2005 23:13:30 +0100, Felix Kühling <[EMAIL PROTECTED]> wrote:
> > This scheme would give good results with movie players that need fast
> > texture uploads and typically use each texture exactly once. It would
>
> Movi
Felix Kühling wrote:
I simplified this idea a little further and attached a patch against
texmem.[ch]. It frees stale textures (and also place holders for other
clients' textures) that havn't been used in 1 second when it runs out of
space on a texture heap. This way it will try a bit harder to put
>
> A better scheme for a movie player would be to create a single texture
> and then keep replacing it's contents. Or use two textures and double
> buffer. But once created these textures would not move in the LRU list
> unless you started something like a game in another window.
if we supported
AGP 8x should just be able to keep up with 1280x1024x24b 60 times/sec.
How does mesa access AGP memory from the CPU side? AGP memory is
system memory which the AGP makes visible to the GPU. Are we using
the GPU to load textures into AGP memory or is it being done entirely
on the main CPU with a m
Jon Smirl wrote:
AGP 8x should just be able to keep up with 1280x1024x24b 60
times/sec.
AGP 4x should be enough. Remember I got 600MB/s max throughput. Not with
24bit textures though, the Mesa RGBA-BGRA conversion takes WAY too much
time to achieve that.
How does mesa access AGP memory from the CP
Felix Kühling wrote:
I don't think my algorithm is much more complicated. It can be
implemented by gradual improvements of the current algorithm (freeing
stale texture memory is one step) which helps avoiding unexpected
performance regressions. At the moment I'm not planning to rewrite it
from scra
Dave Airlie wrote:
A better scheme for a movie player would be to create a single texture
and then keep replacing it's contents. Or use two textures and double
buffer. But once created these textures would not move in the LRU list
unless you started something like a game in another window.
if we s
On Thu, 10 Feb 2005 21:59:29 -0500, Owen Taylor <[EMAIL PROTECTED]> wrote:
> That should allow a straight-copy from data you create to memory card
> the can texture from, which is about as good as possible.
If you have a big AGP aperture to play with there is a faster way.
When you get the call to
On Thu, 2005-02-10 at 22:23 -0500, Jon Smirl wrote:
> On Thu, 10 Feb 2005 21:59:29 -0500, Owen Taylor <[EMAIL PROTECTED]> wrote:
> > That should allow a straight-copy from data you create to memory card
> > the can texture from, which is about as good as possible.
>
> If you have a big AGP apertur
Hi Ben,
Great work !
With regards to discard buffer command - now that I think of it, you
want this code initiated from within cmdbuf, not as a separate ioctl, so
your way is correct - we need to implement the appropriate cmd for r300.
Go ahead and apply the patch, can't wait to try it
> > it. Instead mark it's page table entries as copy on write. Get the
> > physical address of the page and set it into the GART. Now the GPU can
> > get to it with zero copies. When you are done with it, check and see
> > if the app caused a copy on write, if so free the page, else just
> > remove
On Thu, 10 Feb 2005 20:14:00 -0800, Eric Anholt <[EMAIL PROTECTED]> wrote:
> Is there evidence that this is/would be in fact faster?
That's how the networking drivers work and they may be the fastest
drivers in the system.
But, it has not been coded for AGP so nobody knows for sure. It has to
be f
38 matches
Mail list logo
