Alex Deucher wrote:
--- Felix Kühling <[EMAIL PROTECTED]> wrote:
Thanks for your explanation. I think I'm beginning to understand. To
get
this straight, access to the frame buffer by the 2D engine, 3D engine
and the CPU all go through bitmap descriptors which can translated
from/to tiled/linear
On Iau, 2004-01-15 at 20:47, Alex Deucher wrote:
> Makes sense. I know what might help clear this up. Alan, do you still
> have a copy of the VIA/S3 source with pbuffer support? I'm curious as
> to how they did it.
On the VIA pbuffer is unaccelerated, the 2D memory view is also linear
although th
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Alex Deucher wrote:
>
> > I think in theory anyone (2D, 3D, CPU) can write to any BD it as
> long
> > as it is selected as the destination of that operation. you can
> even
> > set one BD as a source and another as a destination I think.
> Perhaps
>
Alex Deucher wrote:
I think in theory anyone (2D, 3D, CPU) can write to any BD it as long
as it is selected as the destination of that operation. you can even
set one BD as a source and another as a destination I think. Perhaps
Tim can clarify this.
I would think you would have to be able to d
--- Felix Kühling <[EMAIL PROTECTED]> wrote:
> Thanks for your explanation. I think I'm beginning to understand. To
> get
> this straight, access to the frame buffer by the 2D engine, 3D engine
> and the CPU all go through bitmap descriptors which can translated
> from/to tiled/linear adresses. Th
Thanks for your explanation. I think I'm beginning to understand. To get
this straight, access to the frame buffer by the 2D engine, 3D engine
and the CPU all go through bitmap descriptors which can translated
from/to tiled/linear adresses. The format is somehow specified by the
tiled surface regis
I fixed the pitch in savagespan today. my assumption was right. see
more below.
Alex
--- Felix Kühling <[EMAIL PROTECTED]> wrote:
> Alex,
>
> honestly I don't understand much of what you were writing about
> tiling
> registers, PBDs, GBDs and so on. I don't have much experience with
> low
> le
Alex,
honestly I don't understand much of what you were writing about tiling
registers, PBDs, GBDs and so on. I don't have much experience with low
level aspects of graphics engines. The last one I programmed on the
register level was an original VGA under DOS many years ago. ;-) I'm a
bit confuse
Felix,
Last night I did some thinging about the pitch and linear vs. tiled
mode. To be honest, I don't think it matters. 2D uses the GBD and can
be tiled or linear. 3D uses the PBD and has to be tiled. Since they
are using different BDs, it shouldn't matter whether 2D is tiled or
not. for
On Sun, 11 Jan 2004 09:31:05 -0800 (PST)
Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> --- Felix K_hling <[EMAIL PROTECTED]> wrote:
> > On Fri, 9 Jan 2004 16:00:46 -0800 (PST)
> > Alex Deucher <[EMAIL PROTECTED]> wrote:
> >
> > > whoops. I'll have to check that out. Can you point me to the
> > c
--- Felix Kühling <[EMAIL PROTECTED]> wrote:
> On Fri, 9 Jan 2004 16:00:46 -0800 (PST)
> Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> > whoops. I'll have to check that out. Can you point me to the
> code?
> > I'm assuming savage_span in the DRI somewhere? Also, only 16 bpp
> works
> > at the m
On Fri, 9 Jan 2004 16:00:46 -0800 (PST)
Alex Deucher <[EMAIL PROTECTED]> wrote:
> whoops. I'll have to check that out. Can you point me to the code?
> I'm assuming savage_span in the DRI somewhere? Also, only 16 bpp works
> at the moment on savage4. I've only been able to run one 3d app at 32
On Fri, 2004-01-09 at 14:40, Alex Deucher wrote:
> er... well, the bitmap descriptor speed up in my last email was a
> fluke... that code I changed never actually gets run, so the speed up
> was just a random fluke I guess.
>
> What is SavageInitBuffers() in savage_dri.c supposed to do? all of it
On Fri, 9 Jan 2004 16:00:46 -0800 (PST)
Alex Deucher <[EMAIL PROTECTED]> wrote:
> whoops. I'll have to check that out. Can you point me to the code?
> I'm assuming savage_span in the DRI somewhere? Also, only 16 bpp works
The span stuff itself is in savagespan.c in the Mesa driver. However, i
whoops. I'll have to check that out. Can you point me to the code?
I'm assuming savage_span in the DRI somewhere? Also, only 16 bpp works
at the moment on savage4. I've only been able to run one 3d app at 32
bpp, glxheads from the mesa demos. all the rest spit out this error
message:
savagedm
I just noticed that your changes broke the line pitch in the span
functions (again). You see the effect when you run xscreensaver hacks with
-fps. I'll see if I can fix it once more. ;-)
Felix
On Fri, 9 Jan 2004 12:45:10 -0800 (PST)
Alex Deucher <[EMAIL PROTECTED]> wrote:
> The attached patch is
er... well, the bitmap descriptor speed up in my last email was a
fluke... that code I changed never actually gets run, so the speed up
was just a random fluke I guess.
What is SavageInitBuffers() in savage_dri.c supposed to do? all of its
content is commented out. it seems to contain the actual
I tested your patch on my ProSavage. It works and it speeds up glxgears
by over 50fps. I was surprised to read numbers over 500fps on Savage4 as
that's about what I'm getting with ProSavage too. It used to be about
490, with your patch it's about 550 now.
BTW, I just saw your other mail about the
The attached patch is a cleaned up version of the one I made this
morning. It enables DRI support for savage4 and shouldn't break
prosavage or twister, however, I'd like someone with prosvage or
twister to check it out before I commit it.
Both tiled and linear framebuffer mode now work with 3D.
19 matches
Mail list logo
