Announcement

Collapse
No announcement yet.

A New ATI X.Org Driver Has Been Released

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by bridgman View Post
    AFAIK you need new bits all round for tiling to work.
    I don't get what tiling is exactly.
    Can someone point me toward a ussefull glossary source for all of this magic words ?
    Blit, Tiling, Stencil buffer...

    Comment


    • #12
      It optimises the layout of images in memory by putting pixels which are close to each other in the image close to each other in the memory.

      You don't notice it at all, other than through improved performance.

      Comment


      • #13
        - Blit
        - Stencil Buffer
        - Tiling refers to a more complex, but faster memory-layout. Instead of storing pixels line by line, they're either stored as a series of small square blocks, or they're stored in the order of a Space filling curve. In both cases, pixels that are close in the image are more likely to be close in video memory, resulting in better cache locality, thus more speed.
        (The best memory layout for the render target is closely tied to the way the rasterizer works; it has a specific memory access pattern that needs to be accommodated. The best memory layout for textures etc. depends on the specific shader's access patterns, but better cache locality is usually a good thing.)

        Comment


        • #14
          Tiling requires support in the drm (2.6.36), ddx (6.13.2), and mesa (7.9).

          Comment


          • #15
            Yeah, as an example think of the lines of pixels on your monitor.

            A simple layout would put each pixel into memory in order line by line, but then the 1st pixel on the 1st line is nowhere near the 1st pixel on the 2nd line, even though they are right next to each other on your monitor and will likely need to be accessed at the same time. Tiling makes sure nearby pixels are nearby in memory as well, which allows caching to be much more effective (and therefore speeds everything up).

            Comment


            • #16
              @agd5f:

              Could you include that kind of info in the release announcements in the future?
              It's usually pretty hard to find out what versions are required for what.

              Comment


              • #17
                And blitting is moving textures around on the framebuffer, or the shadow_fb.

                Having this accelerated means better performance. For example if you play a side scroller game and you have multiple sprites that all move around

                Comment


                • #18
                  And stencil buffers could be used for this:

                  You see these overlapping shadows in effect in Doom 3?; the stencil buffer uses the depth buffer for determing what overlaps what and then this can be used for effects like overlapping shadows.

                  Comment


                  • #19
                    After using this for a while, I find it's a bit slower than 6.13.1.

                    The performance loss isn't big enough to bother bisecting, nor do I have an automatable test case (scrolling a web page is where I noticed this).

                    I have an older environment (xorg 1.7.7, 2.6.33.7, mesa 7.8.2), but it would be expected not to regress while adding support for new shinies.

                    Not sure at all if this info would be useful to the devs, thus posting here. :P

                    Comment


                    • #20
                      Originally posted by curaga View Post
                      After using this for a while, I find it's a bit slower than 6.13.1.

                      The performance loss isn't big enough to bother bisecting, nor do I have an automatable test case (scrolling a web page is where I noticed this).

                      I have an older environment (xorg 1.7.7, 2.6.33.7, mesa 7.8.2), but it would be expected not to regress while adding support for new shinies.

                      Not sure at all if this info would be useful to the devs, thus posting here. :P


                      It's probably due to Karl's changes to improve the handling of software fallbacks. Things like image view and videos in firefox are now much faster, however certain other operations seem to be slightly slower now. The basic problem is how to handle sw fallbacks properly. Sending buffers back and furth across the bus is a performance killer, so there are ways to to mitigate that depending on the type of operation (e.g., read vs write, size of pixmap, etc.), however, there are always lots of corner cases. Unfortunately, we probably need better logic in the core EXA code to properly handle all these corner cases.

                      Comment

                      Working...
                      X