Re: Is there the possibility to support EXA for legacy S3 chips?
On Thu, 2009-06-04 at 19:54 +0400, Evgeny M. Zubok wrote: Michel Dänzer mic...@daenzer.net writes: EXA bug: Calling FinishAccess on pixmap 0x9278d68 with index 1 while it should have been (nil). This may indeed be a bug, Maarten? Might be interesting to see gdb backtraces for when these trigger. Is the https://bugs.freedesktop.org/show_bug.cgi?id=20212 relevant? Possibly. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
On Thu, 2009-05-28 at 15:07 +0400, Evgeny M. Zubok wrote: Ville Syrjälä syrj...@sci.fi writes: Just set the alignment to your fixed pitch value and it should work, shouldn't it? Great! Good idea! I have tried to set up pitch align pEXA-pixmapPitchAlign = pScrn-displayWidth * pS3-s3Bpp; and got almost normal working screen (with artefacts though) but not so ugly as before. I think that it may be bug somewhere in EXA or driver bacause server's log is full of error messages. ... EXA bug: Calling FinishAccess on pixmap 0x9278d68 with index 1 while it should have been (nil). This may indeed be a bug, Maarten? Might be interesting to see gdb backtraces for when these trigger. However the main problem with this method is that memory manager doesn't effectively use the offscreen in this case. Indeed, I'm afraid EXA just doesn't offer any advantages over XAA for such limited hardware. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
Michel Dänzer mic...@daenzer.net writes: EXA bug: Calling FinishAccess on pixmap 0x9278d68 with index 1 while it should have been (nil). This may indeed be a bug, Maarten? Might be interesting to see gdb backtraces for when these trigger. Is the https://bugs.freedesktop.org/show_bug.cgi?id=20212 relevant? However the main problem with this method is that memory manager doesn't effectively use the offscreen in this case. Indeed, I'm afraid EXA just doesn't offer any advantages over XAA for such limited hardware. I have the same thoughts now. In addition I discovered that S3 couldn't copy pixmaps with different colour depth from offscreen. For example, when using 16 bpp framebuffer. Some source pixmaps have 16 bpp, and others have 32 bpp. This results to incorrect 32 bpp pixmaps copying into frambuffer. So on S3 the EXA works fine only with 32 bpp fb but not with 16 bpp fb. Other hardware with EXA support have not any problems with different pixmap depths because their depth may be specified for graphic processor. Also my tests showed that drawing speed with EXA on very slow PC was the same as with shadow framebuffer (and less than XAA). Currently I think that EXA support does not make sense for the S3. Only the boards with 4/8 Mb video RAM may be the exception and only for depth 24 / 32 bpp fb. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
On Thu, Jun 4, 2009 at 11:54 AM, Evgeny M. Zubok evgeny.zu...@tochka.ru wrote: Michel Dänzer mic...@daenzer.net writes: EXA bug: Calling FinishAccess on pixmap 0x9278d68 with index 1 while it should have been (nil). This may indeed be a bug, Maarten? Might be interesting to see gdb backtraces for when these trigger. Is the https://bugs.freedesktop.org/show_bug.cgi?id=20212 relevant? However the main problem with this method is that memory manager doesn't effectively use the offscreen in this case. Indeed, I'm afraid EXA just doesn't offer any advantages over XAA for such limited hardware. I have the same thoughts now. In addition I discovered that S3 couldn't copy pixmaps with different colour depth from offscreen. For example, when using 16 bpp framebuffer. Some source pixmaps have 16 bpp, and others have 32 bpp. This results to incorrect 32 bpp pixmaps copying into frambuffer. So on S3 the EXA works fine only with 32 bpp fb but not with 16 bpp fb. Other hardware with EXA support have not any problems with different pixmap depths because their depth may be specified for graphic processor. Also my tests showed that drawing speed with EXA on very slow PC was the same as with shadow framebuffer (and less than XAA). Currently I think that EXA support does not make sense for the S3. Only the boards with 4/8 Mb video RAM may be the exception and only for depth 24 / 32 bpp fb. EXA copy shouldn't ask for blits across color depths (need composite for that), however, it does store buffers of different color depths in offscreen memory, so you'd need to be to adjust the depth of the blitter on the fly. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
2009/6/4 Michel Dänzer mic...@daenzer.net: On Thu, 2009-05-28 at 15:07 +0400, Evgeny M. Zubok wrote: Ville Syrjälä syrj...@sci.fi writes: Just set the alignment to your fixed pitch value and it should work, shouldn't it? Great! Good idea! I have tried to set up pitch align pEXA-pixmapPitchAlign = pScrn-displayWidth * pS3-s3Bpp; and got almost normal working screen (with artefacts though) but not so ugly as before. I think that it may be bug somewhere in EXA or driver bacause server's log is full of error messages. ... EXA bug: Calling FinishAccess on pixmap 0x9278d68 with index 1 while it should have been (nil). This may indeed be a bug, Maarten? Might be interesting to see gdb backtraces for when these trigger. I'm curious as to what triggers this. Can't think of anything from the top of my head. However the main problem with this method is that memory manager doesn't effectively use the offscreen in this case. Indeed, I'm afraid EXA just doesn't offer any advantages over XAA for such limited hardware. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
Michel Dänzer mic...@daenzer.net writes: I think that it may be bug somewhere in EXA or driver bacause server's log is full of error messages. EXA bug: Calling FinishAccess on pixmap 0x9278d68 with index 1 while it should have been (nil). This may indeed be a bug, Maarten? Might be interesting to see gdb backtraces for when these trigger. Specifying EXAOptimizeMigration off solves the problem, but sometimes two or three such messages appear in the log even with this option. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
Looks like no dice for EXA. Fixed pitches, no offsets... ouch. Yes, I think the same. 'Solid' and 'Copy' is the only functionality that would be possible with this hardware. There is no reason to waste a time further. BTW, both 'Solid' and 'Copy' work fine only when operate on framebuffer because fb is always viewed by EXA simultaneously as source and destination pixmap with fixed pitch (in my case 3200 = 800 * 4 bytes) and with offset 0. But when the offscreen is invoked into operation I am getting a garbage on screen. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
Ville Syrjälä syrj...@sci.fi writes: Why wouldn't it work if you just allocate everything using the same pitch? Or does the allocator make some assumptions about the pitches the hardware can handle? The allocator make the assumption that hardware is able to copy offscreen pixmaps with any pitch and with any offset (only alignment can be varied). There is no way to ask EXA always to allocate offscreen pixmaps with fixed pitch. This option would be possible to implement (something like pEXA-offscreenPitch = ...) but the modern and not so modern hardware doesn't need it. Who cared about the ancient S3? :) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
On Thu, May 28, 2009 at 12:00:26PM +0400, Evgeny M. Zubok wrote: Ville Syrjälä syrj...@sci.fi writes: Why wouldn't it work if you just allocate everything using the same pitch? Or does the allocator make some assumptions about the pitches the hardware can handle? The allocator make the assumption that hardware is able to copy offscreen pixmaps with any pitch and with any offset (only alignment can be varied). There is no way to ask EXA always to allocate offscreen pixmaps with fixed pitch. This option would be possible to implement (something like pEXA-offscreenPitch = ...) but the modern and not so modern hardware doesn't need it. Who cared about the ancient S3? :) Just set the alignment to your fixed pitch value and it should work, shouldn't it? -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
Ville Syrjälä syrj...@sci.fi writes: Just set the alignment to your fixed pitch value and it should work, shouldn't it? Great! Good idea! I have tried to set up pitch align pEXA-pixmapPitchAlign = pScrn-displayWidth * pS3-s3Bpp; and got almost normal working screen (with artefacts though) but not so ugly as before. I think that it may be bug somewhere in EXA or driver bacause server's log is full of error messages. ... EXA bug: Calling FinishAccess on pixmap 0x9278d68 with index 1 while it should have been (nil). EXA bug: Calling FinishAccess on pixmap 0x921a2e0 with index 1 while it should have been (nil). EXA bug: Calling FinishAccess on pixmap 0x921a2e0 with index 1 while it should have been (nil). ... However the main problem with this method is that memory manager doesn't effectively use the offscreen in this case. To allocate tiny pixmap with w,h = (4,4) in 800x600/32bpp the 4 * 3200 = 12800 bytes (with alignment 800 * 4 bytes for colour) is required. I verified that by printing exaPixmapSize for every offscreen pixmap. The offscreen memory manager is not so smart to allocate the pixmap 2 on the same scanlines within reserved area for pixmap's 1 alignment. It can be placed only after last row of previous pixmap (see pixmap 2'). When the size of video RAM is very limited this becomes meaningless (for 800x600/32bpp, 2Mb RAM , the offscreen is about 171 kB -- total height of stored pixmaps is 55). --- 800 * 4 Bpp 0 == - . == | . == | . == 600 scanlines (Framebuffer) . == | 599 == | 600 ++ - . | 1 |=+---+== | . ||=| 2 |== | . ++=+---+== 55 scanlines (Offscreen) . +---+= | . | 2'|= | 654 +---+= - But anyway, thanks for idea. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Is there the possibility to support EXA for legacy S3 chips?
I have made the first attempt to implement basic `Copy' and `Solid' EXA functions in xf86-video-s3, but soon came to intention that EXA support is not possible. Is there mistake in my thinking below? S3's Graphic Processor (S3 GP) is able to copy areas only in terms of coordinates, i. e. it can copy rectangle from (src-x, src-y) to (dest-x, dest-y) with width w and height h (Fig. 1). This method is used in XAA ScreenToScreenCopy function. But S3 GP hasn't mean to copy offscreen pixmaps in format presented on Fig. 2 to framebuffer, i. e. there is no way to write the pixmap's offset and pitch directly into GP registers to make subsequent copying. I looked up on the code of few other drivers where EXA is implemented (ati, trident, mga) -- all these chips have the possibility to write offset and pitch of pixmap into their GP. Although the method (by means of Pixel Transfer Register) exists to upload pixmap from the system memory to S3's offscreen memory in required format (Fig. 1) (I didn't try it), such offscreen memory organization will not be understandable to the EXA offscreen memory manager. Most probably this will follow to incorrect pixmap migration and overwriting previously uploaded pixmaps. The objection above sounds like the judgement to EXA support in S3 driver. No? --- 800 * 4 Bpp 0 == - . ===11= | . ===22= | . ===33= 600 scanlines (Framebuffer) . ===44= | 599 == | 600 11 - . 22 | . 33 | . 44 55 scanlines (Offscreen) . == | . == | 654 == - Fig. 1. S3 GP fb and offscreen representation, 800x600/32bpp, 2Mb video RAM (655 scanlines). --- 800 * 4 Bpp 0 == - . ===11= | . ===22= | . ===33= 600 scanlines (Framebuffer) . ===44= | 599 == | 600 112233 - . 44 | . == | . == 55 scanlines (Offscreen) . == | . == | 654 == - Fig. 2. EXA Pixmap in offscreen, 800x600/32bpp, 2Mb video RAM (655 scanlines) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
On Wed, May 27, 2009 at 5:09 PM, Evgeny M. Zubok evgeny.zu...@tochka.ru wrote: I have made the first attempt to implement basic `Copy' and `Solid' EXA functions in xf86-video-s3, but soon came to intention that EXA support is not possible. Is there mistake in my thinking below? S3's Graphic Processor (S3 GP) is able to copy areas only in terms of coordinates, i. e. it can copy rectangle from (src-x, src-y) to (dest-x, dest-y) with width w and height h (Fig. 1). This method is used in XAA ScreenToScreenCopy function. But S3 GP hasn't mean to copy offscreen pixmaps in format presented on Fig. 2 to framebuffer, i. e. there is no way to write the pixmap's offset and pitch directly into GP registers to make subsequent copying. I looked up on the code of few other drivers where EXA is implemented (ati, trident, mga) -- all these chips have the possibility to write offset and pitch of pixmap into their GP. Although the method (by means of Pixel Transfer Register) exists to upload pixmap from the system memory to S3's offscreen memory in required format (Fig. 1) (I didn't try it), such offscreen memory organization will not be understandable to the EXA offscreen memory manager. Most probably this will follow to incorrect pixmap migration and overwriting previously uploaded pixmaps. The objection above sounds like the judgement to EXA support in S3 driver. No? Looks like no dice for EXA. Fixed pitches, no offsets... ouch. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
On Wed, May 27, 2009 at 6:20 PM, Ville Syrjälä syrj...@sci.fi wrote: On Wed, May 27, 2009 at 05:50:51PM -0400, Alex Deucher wrote: On Wed, May 27, 2009 at 5:09 PM, Evgeny M. Zubok evgeny.zu...@tochka.ru wrote: I have made the first attempt to implement basic `Copy' and `Solid' EXA functions in xf86-video-s3, but soon came to intention that EXA support is not possible. Is there mistake in my thinking below? S3's Graphic Processor (S3 GP) is able to copy areas only in terms of coordinates, i. e. it can copy rectangle from (src-x, src-y) to (dest-x, dest-y) with width w and height h (Fig. 1). This method is used in XAA ScreenToScreenCopy function. But S3 GP hasn't mean to copy offscreen pixmaps in format presented on Fig. 2 to framebuffer, i. e. there is no way to write the pixmap's offset and pitch directly into GP registers to make subsequent copying. I looked up on the code of few other drivers where EXA is implemented (ati, trident, mga) -- all these chips have the possibility to write offset and pitch of pixmap into their GP. Although the method (by means of Pixel Transfer Register) exists to upload pixmap from the system memory to S3's offscreen memory in required format (Fig. 1) (I didn't try it), such offscreen memory organization will not be understandable to the EXA offscreen memory manager. Most probably this will follow to incorrect pixmap migration and overwriting previously uploaded pixmaps. The objection above sounds like the judgement to EXA support in S3 driver. No? Looks like no dice for EXA. Fixed pitches, no offsets... ouch. Why wouldn't it work if you just allocate everything using the same pitch? Or does the allocator make some assumptions about the pitches the hardware can handle? The allocator doesn't support a fixed pitch, only pitch alignment. You could probably hack something together and disable offscreen pixmaps, but I don't think it would be worth the effort as you'd probably end up falling back in a lot of cases and the lack offscreen pixmaps would hurt performance. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
On Wed, May 27, 2009 at 05:50:51PM -0400, Alex Deucher wrote: On Wed, May 27, 2009 at 5:09 PM, Evgeny M. Zubok evgeny.zu...@tochka.ru wrote: I have made the first attempt to implement basic `Copy' and `Solid' EXA functions in xf86-video-s3, but soon came to intention that EXA support is not possible. Is there mistake in my thinking below? S3's Graphic Processor (S3 GP) is able to copy areas only in terms of coordinates, i. e. it can copy rectangle from (src-x, src-y) to (dest-x, dest-y) with width w and height h (Fig. 1). This method is used in XAA ScreenToScreenCopy function. But S3 GP hasn't mean to copy offscreen pixmaps in format presented on Fig. 2 to framebuffer, i. e. there is no way to write the pixmap's offset and pitch directly into GP registers to make subsequent copying. I looked up on the code of few other drivers where EXA is implemented (ati, trident, mga) -- all these chips have the possibility to write offset and pitch of pixmap into their GP. Although the method (by means of Pixel Transfer Register) exists to upload pixmap from the system memory to S3's offscreen memory in required format (Fig. 1) (I didn't try it), such offscreen memory organization will not be understandable to the EXA offscreen memory manager. Most probably this will follow to incorrect pixmap migration and overwriting previously uploaded pixmaps. The objection above sounds like the judgement to EXA support in S3 driver. No? Looks like no dice for EXA. Fixed pitches, no offsets... ouch. Why wouldn't it work if you just allocate everything using the same pitch? Or does the allocator make some assumptions about the pitches the hardware can handle? -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
On 2009/05/27 18:34 (GMT-0400) Alex Deucher composed: ...the lack offscreen pixmaps would hurt performance. I'm just an observer whose only real interest is in seeing to it that dropping of any legacy support is not done casually. I can only wonder if anyone using a 12 year old legacy chip has any interest in performance beyond just working at all. Surely best possible performance is a worthy goal, but does anyone running antique S3 expect anything more than adequately functional? -- A fool gives full vent to his anger, but a wise man keeps himself under control. Proverbs 29:11 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
From a performance pov an accelerated shadow framebuffer arrangement is probably much faster. Assuming it has some dma capability. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
