Re: xaa vs. WriteImage()

2008-03-07 Thread Marc Aurele La France

On Wed, 5 Mar 2008, Michael Lorenz wrote:
Otherwise, teaching the framebuffer layer to cope with a tiled framebuffer 
might be necessary in the long run, any pointers where to start?


By design, this is a driver issue, as it is responsible for providing VRAM 
access to the rest of the server.



Really. Now /that/ was helpful. Guess I'm on my own here.


Not really.  This sounds like the kind of thing that is right up the 
mibank screen wrapper's alley, assuming the tiles are all the same size.


mibank can interoperate with any other screen wrapper (including XAA), 
except shadowfb, because the later is not a true screen wrapper.


An example of the use of mibank can be found in ATIPreInit() and 
ATIScreenInit().  Mine, that is;  not X.Org's lobotomised imitations of 
same.


Marc.

+--+--+
|  Marc Aurele La France   |  work:   1-780-492-9310  |
|  Academic Information and|  fax:1-780-492-1729  |
|Communications Technologies   |  email:  [EMAIL PROTECTED] |
|  352 General Services Building   +--+
|  University of Alberta   |  |
|  Edmonton, Alberta   |Standard disclaimers apply|
|  T6G 2H1 |  |
|  CANADA  |  |
+--+--+
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel


Re: xaa vs. WriteImage()

2008-03-07 Thread Michael Lorenz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On Mar 7, 2008, at 13:03, Marc Aurele La France wrote:


On Wed, 5 Mar 2008, Michael Lorenz wrote:
Otherwise, teaching the framebuffer layer to cope with a tiled  
framebuffer might be necessary in the long run, any pointers  
where to start?


By design, this is a driver issue, as it is responsible for  
providing VRAM access to the rest of the server.



Really. Now /that/ was helpful. Guess I'm on my own here.


Not really.  This sounds like the kind of thing that is right up  
the mibank screen wrapper's alley, assuming the tiles are all the  
same size.


They are, always 64KB, depending on colour depth they're 512x128,  
256x128 or 128x128 pixels.


mibank can interoperate with any other screen wrapper (including  
XAA), except shadowfb, because the later is not a true screen wrapper.


An example of the use of mibank can be found in ATIPreInit() and  
ATIScreenInit().  Mine, that is;  not X.Org's lobotomised  
imitations of same.


That sounds like it's what I need, thanks!

have fun
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR9GKRspnzkX8Yg2nAQK9fwf/bNN+ZV299AWKn2PFcLi67H82tH6JoSTd
Ykhwgnai7fw8iMhY9wPIK3nbYkWaEE88CdQ8ZzEyYVGcPix+XDydo+kbs5xSPvNr
+t+YHWabiyopbq3YjE1QXUzh6xNwknMRSuGo6iEzWSUhQfxpwzPNwXePZK7+PDdw
1OhKu9QpI8jxLqQOoH5BYTteK8leuVx15E+m1hXhIgFbrdnIgzF7bSnD5SkJwqou
QEnXXGY+A1Tx60RfrZssFDSA1+TnINKN55jJFRBWCC5DYRitFpRdXVqfyZdPU4dt
aW5qVAPk8NJl2/+Ck5tJrjvoBqo8dxl7MCGjBqkDRMFS/To2XKYBYQ==
=kP5V
-END PGP SIGNATURE-
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel


Re: xaa vs. WriteImage()

2008-03-06 Thread Alex Deucher
On Thu, Mar 6, 2008 at 4:26 PM, Michael Lorenz [EMAIL PROTECTED] wrote:
 -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1

  Hello,



 On Mar 6, 2008, at 15:58, Alex Deucher wrote:

   On Thu, Mar 6, 2008 at 2:58 PM, Michael Lorenz
   [EMAIL PROTECTED] wrote:
   -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
  
Hello,
  
On Mar 6, 2008, at 14:12, Alex Deucher wrote:
  
   On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz
   [EMAIL PROTECTED] wrote:
   -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
  
Hello,
  
On Mar 5, 2008, at 19:06, Alex Deucher wrote:
  
   On Tue, Mar 4, 2008 at 5:34 PM, Michael Lorenz
   [EMAIL PROTECTED] wrote:
   -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
  
Hello,
  
  
   On Mar 4, 2008, at 15:37, Marc Aurele La France wrote:
  
   On Mon, 3 Mar 2008, Michael Lorenz wrote:
  
   I noticed the following - XAACopyArea() only attempts to use
   accelerated WriteImage() when writing to a DRAWABLE_WINDOW but
   not
   on off-screen pixmaps. I used the following changes to make it
   work:
  
   diff -u -w -r1.1.1.3 xaaCpyArea.c
   - --- xaaCpyArea.c   9 Jun 2001 15:09:02 -   1.1.1.3
   +++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
   @@ -64,9 +64,16 @@
  return (XAABitBlt( pSrcDrawable, pDstDrawable,
pGC, srcx, srcy, width, height, dstx, dsty,
XAADoBitBlt, 0L));
   +} else {
   +if(infoRec-ScreenToScreenBitBlt 
   + CHECK_ROP(pGC,infoRec-ScreenToScreenBitBltFlags) 
   + CHECK_ROPSRC(pGC,infoRec-
   ScreenToScreenBitBltFlags) 
   + CHECK_PLANEMASK(pGC,infoRec-
   ScreenToScreenBitBltFlags))
   +return (XAABitBlt( pSrcDrawable, pDstDrawable,
   +pGC, srcx, srcy, width, height, dstx, dsty,
   +XAADoImageWrite, 0L));
}
  }
  
   This does not look correct.  Shouldn't this be more in line with
   the case where the destination drawable is a window?  (i.e. test
   bitsPerPixel's and WritePixmap files instead of
   ScreenToScreenBitBlt).
  
The whole logic looks a little bit fishy, I used the first if
   ()'s
source-in-memory branch first but wasn't quite sure if that's
   doing
the right thing, where it;s now looked better to me but I won't
   claim
I completely understand XAA's inner voodoo. All I want is the
   make
XAA use ImageWrite()s for all RAM-to-VRAM transfers if the
   driver
supports it.
Otherwise, teaching the framebuffer layer to cope with a tiled
framebuffer might be necessary in the long run, any pointers
   where to
start?
  
   Several drivers (radeon, intel, savage) in the Xorg tree provide
   support for various tiling methods.  Generally the chip provides a
   surface control or aperture for exposing a tiled region to the
   CPU as
   a linear surface.  For acceleration, you have to keep track of
   what
   buffers are tiled in the driver and do the right thing with the
   blitter when using those surfaces.
  
Yeah, I'm dimly aware of these things - my problem is that the
hardware in question doesn't give me a linear view on the
   framebuffer.
All I have is a small linear buffer I can use to DMA data in or
   out
of the tiled framebuffer. The other problem is that the machine's
native pixel format is RGBA, if I want 24bit colour that's the
   only
one I can use. Fortunately the DMA engine can convert pixels on
   the
fly so I can pretend it's ABGR. So pixels would have to be endian-
flipped as well when the fb layer accesses VRAM - is there any
   prior
art for that?
  
   EXA has prepare/finish access hooks for CPU access to buffers.  I
   don't think XAA has anything similar.  There's also an wrapable FB
   module, although I think it's only available in Xorg.
  
I'll have a look at that - the main reason I'm using XFree86 is that
it's already working on NetBSD/sgimips, Xorg needs some more work
   but
I'll eventually do it.
Hmm, some drivers access video memory through tiny apertures like
   the
VGA range - maybe I can do something like this - let the rest of the
Xserver render into my DMA buffer and then blit it in place.
  
   Use shadowfb and hook in a custom shadowupdate() function.

  Wouldn't that interfere with XAA? If I could catch the framebuffer
  writes that bypass XAA that way that would solve my problem.
  Thanks!

Yeah, you gotta pick one or the other IIRC.  However for most modern
desktops you either have to be entirely SW or entirely HW or
performance sucks.  You lose if any sort of fallbacks cause a pixmap
migration to/from vram.

Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel


Re: xaa vs. WriteImage()

2008-03-06 Thread Alex Deucher
On Thu, Mar 6, 2008 at 5:17 PM, Michael Lorenz [EMAIL PROTECTED] wrote:
 -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1

  Hello,

  On Mar 6, 2008, at 16:40, Alex Deucher wrote:

   On Thu, Mar 6, 2008 at 4:26 PM, Michael Lorenz
   [EMAIL PROTECTED] wrote:
   On Mar 6, 2008, at 15:58, Alex Deucher wrote:
  
   On Thu, Mar 6, 2008 at 2:58 PM, Michael Lorenz
   [EMAIL PROTECTED] wrote:
   -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
  
Hello,
  
On Mar 6, 2008, at 14:12, Alex Deucher wrote:
  
   On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz
   EXA has prepare/finish access hooks for CPU access to buffers.  I
   don't think XAA has anything similar.  There's also an wrapable FB
   module, although I think it's only available in Xorg.
  
I'll have a look at that - the main reason I'm using XFree86 is
   that
it's already working on NetBSD/sgimips, Xorg needs some more work
   but
I'll eventually do it.
Hmm, some drivers access video memory through tiny apertures like
   the
VGA range - maybe I can do something like this - let the rest
   of the
Xserver render into my DMA buffer and then blit it in place.
  
   Use shadowfb and hook in a custom shadowupdate() function.
  
Wouldn't that interfere with XAA? If I could catch the framebuffer
writes that bypass XAA that way that would solve my problem.
Thanks!
  
   Yeah, you gotta pick one or the other IIRC.  However for most modern
   desktops you either have to be entirely SW or entirely HW or
   performance sucks.  You lose if any sort of fallbacks cause a pixmap
   migration to/from vram.

  In my case VRAM is RAM, and the CPU is pretty slow - I've had things
  running entirely SW and performance sucked. Not the slowest I've ever
  seen but nowhere near what the HW can do.
  Also, many X applications have trouble with the HW's native pixel
  format, cairo for instance just crashes. Using the DMA engine I can
  pretend it's using something more common - ABGR - and those
  applications just work fine. I think the next thing I'll try is to
  pretend that we're accessing VRAM through a small window, there must
  be prior art for that somewhere in the source tree.


the sgi impact driver I mentioned before
(http://cgit.freedesktop.org/xorg/driver/xf86-video-impact/) does
that.  IIRC, there's no way to access the vram directly so everything
gets sent to the card via dma.

Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel


Re: xaa vs. WriteImage()

2008-03-06 Thread Michael Lorenz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On Mar 6, 2008, at 18:02, Alex Deucher wrote:

On Thu, Mar 6, 2008 at 5:17 PM, Michael Lorenz  
[EMAIL PROTECTED] wrote:

-BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello,

 On Mar 6, 2008, at 16:40, Alex Deucher wrote:


On Thu, Mar 6, 2008 at 4:26 PM, Michael Lorenz
[EMAIL PROTECTED] wrote:

On Mar 6, 2008, at 15:58, Alex Deucher wrote:


On Thu, Mar 6, 2008 at 2:58 PM, Michael Lorenz
[EMAIL PROTECTED] wrote:

-BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello,

 On Mar 6, 2008, at 14:12, Alex Deucher wrote:


On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz
EXA has prepare/finish access hooks for CPU access to  
buffers.  I
don't think XAA has anything similar.  There's also an  
wrapable FB

module, although I think it's only available in Xorg.


 I'll have a look at that - the main reason I'm using XFree86 is
that
 it's already working on NetBSD/sgimips, Xorg needs some more  
work

but
 I'll eventually do it.
 Hmm, some drivers access video memory through tiny apertures  
like

the
 VGA range - maybe I can do something like this - let the rest
of the
 Xserver render into my DMA buffer and then blit it in place.


Use shadowfb and hook in a custom shadowupdate() function.


 Wouldn't that interfere with XAA? If I could catch the framebuffer
 writes that bypass XAA that way that would solve my problem.
 Thanks!


Yeah, you gotta pick one or the other IIRC.  However for most modern
desktops you either have to be entirely SW or entirely HW or
performance sucks.  You lose if any sort of fallbacks cause a pixmap
migration to/from vram.


 In my case VRAM is RAM, and the CPU is pretty slow - I've had things
 running entirely SW and performance sucked. Not the slowest I've  
ever

 seen but nowhere near what the HW can do.
 Also, many X applications have trouble with the HW's native pixel
 format, cairo for instance just crashes. Using the DMA engine I can
 pretend it's using something more common - ABGR - and those
 applications just work fine. I think the next thing I'll try is to
 pretend that we're accessing VRAM through a small window, there must
 be prior art for that somewhere in the source tree.



the sgi impact driver I mentioned before
(http://cgit.freedesktop.org/xorg/driver/xf86-video-impact/) does
that.  IIRC, there's no way to access the vram directly so everything
gets sent to the card via dma.


Yeah, that's the software-only case. Interesting but I'd rather find  
a way to make this work while being able to use the rendering engine.


have fun
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR9B8FcpnzkX8Yg2nAQIe8Qf9FN2yZYRhGQv9f6B+ljBbkbIUx/8yXSe9
T9i4tMWGH5p1RnzoSU0GX8qHmmF8lm2ajMKI8yY496+Kma34NiPUN2QgrRJJrlen
yG2WOydYC1iqCYj+MA3pfJ3Nqns/xMJDj24BWVfpQGDDEHEaegjIcFpsXH5MW++W
dQbojEECbMFivSmTAuZ3u/YmfDskw6TqE+fTBGLLXurmnQY0lFok1IUeyS7dITuw
A5L2BJJMFjvP32uglb6LGUlw921Aj5o7kMEI7VBvJx8lgoTBPmT+lwXaacUbQ2iv
bG9+GFctpswI9nuI/CDNhvdKyMHlgUieYn9nHX90VQuGil02AvfpFw==
=t834
-END PGP SIGNATURE-
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel


Re: xaa vs. WriteImage()

2008-03-04 Thread Marc Aurele La France

On Mon, 3 Mar 2008, Michael Lorenz wrote:

I noticed the following - XAACopyArea() only attempts to use accelerated 
WriteImage() when writing to a DRAWABLE_WINDOW but not on off-screen pixmaps. 
I used the following changes to make it work:



diff -u -w -r1.1.1.3 xaaCpyArea.c
- --- xaaCpyArea.c  9 Jun 2001 15:09:02 -   1.1.1.3
+++ xaaCpyArea.c3 Mar 2008 20:51:05 -
@@ -64,9 +64,16 @@
   return (XAABitBlt( pSrcDrawable, pDstDrawable,
pGC, srcx, srcy, width, height, dstx, dsty,
XAADoBitBlt, 0L));
+   } else {
+   if(infoRec-ScreenToScreenBitBlt 
+CHECK_ROP(pGC,infoRec-ScreenToScreenBitBltFlags) 
+CHECK_ROPSRC(pGC,infoRec-ScreenToScreenBitBltFlags) 
+CHECK_PLANEMASK(pGC,infoRec-ScreenToScreenBitBltFlags))
+return (XAABitBlt( pSrcDrawable, pDstDrawable,
+   pGC, srcx, srcy, width, height, dstx, dsty,
+   XAADoImageWrite, 0L));
}
   }


This does not look correct.  Shouldn't this be more in line with the case 
where the destination drawable is a window?  (i.e. test bitsPerPixel's and 
WritePixmap files instead of ScreenToScreenBitBlt).



have fun


Always.

Marc.

+--+--+
|  Marc Aurele La France   |  work:   1-780-492-9310  |
|  Academic Information and|  fax:1-780-492-1729  |
|Communications Technologies   |  email:  [EMAIL PROTECTED] |
|  352 General Services Building   +--+
|  University of Alberta   |  |
|  Edmonton, Alberta   |Standard disclaimers apply|
|  T6G 2H1 |  |
|  CANADA  |  |
+--+--+
XFree86 developer and VP.  ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel