Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 6 of 6

Thread: Anti-aliasing support in radeon driver

  1. #1
    Junior Member Newbie
    Join Date
    Feb 2015
    Posts
    15

    Anti-aliasing support in radeon driver

    I am a opengl application and library developer, Currently now I am working on openGL 1.X version, In that I have tried LINE_SMOOTH and POINT_SMOOTH there is no effect in observed in output, I have enabled Blend function also (SRC_ALPHA, ONE_MINUS_SRC_ALPHA). Is there no implementation in r600/r700 drivers in openGL 1.X versions?
    Is that true, How can i draw a smoother line?? I have tried with i915(intel chips), Its drawing a perfect smooth line and points. Kindly help me to solve this issue. Thanks in advance..

  2. #2
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,032
    You've asked this and closely related questions before (back in 2015):

    * Anti-aliasing not working with radeon chip.
    * Multi Sampling buffers not gets enabled.
    * Line smooth not working.

    However, you haven't answered the questions asked nor provided any more information.

    To get some help from folks, please provide:

    1) the specific AMD GPU model,
    2) the GPU driver vendor and version,
    3) the OS,
    4) the windowing system library, and
    5) the GL code you're using to perform your rendering, including your framebuffer/window setup.

    Re #4, are you using EGL, GLX, WGL, or other to setup your OpenGL context and window drawable (you previously said you were using EGL)?

    Also, why are you targeting OpenGL 1.X? Are you sure you're not talking about OpenGL ES? Even then, that's old, but not quite so old.
    Last edited by Dark Photon; 04-07-2017 at 08:01 PM.

  3. #3
    Junior Member Newbie
    Join Date
    Feb 2015
    Posts
    15
    Here are the details for the Hardware and Software environment used:
    Hardware:
    ATI Radeon E4690 with Freescale PowerPC Processor.
    Software:
    Mesa tested versions 8.x and 9.x
    OpenGL ES 1.0 and EGL version 1.4
    Linux kernel 3.10.x

    Since the development is based on embedded environment, we have configured Mesa with EGL without X.
    We are using Mesa gallium r600 driver with EGL configured using EGL_SCREEN_BIT_MESA, to obtain framebuffer drawing without any windowing environment.

    The provision for enabling LINE_SMOOTH and POINT_SMOOTH is available in Mesa r600 driver, although the effect is not visible in the desired environment (mentioned above).
    On the other hand, the same ATI chip when tested with the Anti-aliasing options provided in ATI Catalyst Manager in x86 environment, provides smoothing effects. As per my understanding, it is using MSAA feature in this case, supported by the chip's 3D register set (Also verified by reading the MSAA configuration registers).
    But, when we configured Mesa with GLX and X11 in the same x86 environment, the LINE_SMOOTH functionality (tested with sample OpenGL application) is also providing line smooth effects.
    Although, it is not configuring the MSAA registers (verified by read back).
    How is LINE_SMOOTH working in this environment ? Is it anyway related to GLX and X11 ? Are these entities responsible or it is simply hardware feature ?

    Since, MSAA (Multisampling) is provided from ES 2.0, I require provision to achieve hardware anti-aliasing (with my ATI chip) using ES 1.0 in the framebuffer environment ?

    Any help in this context is appreciated.

    Thanks again.
    Last edited by muthuveera; 04-08-2017 at 03:35 AM.

  4. #4
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,032
    Quote Originally Posted by muthuveera View Post
    Here are the details for the Hardware and Software environment used:
    Hardware:
    ATI Radeon E4690 with Freescale PowerPC Processor.
    Software:
    Mesa tested versions 8.x and 9.x
    OpenGL ES 1.0 and EGL version 1.4
    Linux kernel 3.10.x
    ...
    We are using Mesa gallium r600 driver with EGL
    Thanks! This is helpful.

    So the jist of it is you'd like anti-aliased points and lines. But you're not getting that.

    ...when rendering on a Radeon E4690 through EGL 1.4+OpenGL ES 1.0 provided by an old 8.x-9.x version of Mesa3D, using GL_{LINE,POINT}_SMOOTH.

    However, switching graphics drivers (to AMD/ATI PC drivers), you know that on the same GPU you get nicely antialiased points and lines, with and without MSAA (for the latter, GLX+OpenGL were used with GL_{LINE,POINT}_SMOOTH).

    So you know it's due to either: 1) problems with Mesa3D 8.x/9.x's implementation of GL_{LINE,POINT}_SMOOTH under OpenGL ES / GLX, or 2) your application not doing something properly to activate this support.

    So what to do about it...

    First, point and line smooth were always such non-uniformly supported and inefficiently-implemented features that you might in the end just choose to punt, and instead do something like render your own line quad primitives with MSAA (multisample antialiasing enabled). But let's see whether you can salvage the GL_{POINT,LINE}_SMOOTH path first.

    First thought: Upgrade your https://www.mesa3d.org/ implementation. Maybe it has improved its point/line antialiasing support for your GPU since version 8.x-9.x.

    Second, according to this page at mesa3d.org, Mesa3D's OpenGL ES support is only version 1.1+. Are you sure you're using OpenGL ES 1.0? That said, this page may be a little out-of-date because I know that Mesa3D is supporting OpenGL ES 3.1 and 3.2 on some configurations.

    Third, have you followed the tips here:

    * Common_Mistakes#Point_and_line_smoothing (OpenGL Wiki)

    Make sure your target framebuffer has an alpha channel allocated.

    Fourth, have you tried using multisample line rasterization? It can't hurt to try it.

    Related to this, I don't understand this comment:

    Quote Originally Posted by muthuveera
    Since, MSAA (Multisampling) is provided from ES 2.0...
    Per the OpenGL ES 1.0 spec:
    Quote Originally Posted by OpenGL ES 1.0 Spec
    Multisampling is supported though an implementation is not required to provide a multisample buffer.
    Further, multisample drawables are supported though EGL 1.4. So the question boils down to whether your EGL implementation provides support for allocating multisampled drawables. And you can easily determine that by iterating through the EGLConfigs supported on your hardware with your EGL implementation. See something like this for some starter code. The key thing you're looking for is EGLConfigs which have EGL_SAMPLE_BUFFERS == 1 and EGL_SAMPLES > 1, and which also support one of the drawable types supported on your system (EGL_WINDOW_BIT, EGL_PBUFFER_BIT, EGL_PIXMAP_BIT, and/or EGL_SCREEN_BIT_MESA). If so, allocate an EGL drawable using one of those multisample EGLconfigs, target rendering to it, enable GL_MULTISAMPLE in OpenGL ES, and then just try rasterizing lines with line width.

    Related to this, the OpenGL ES 1.1 spec specifically defines how lines are rasterized when multisampling is enabled to a multisample drawable:

    Quote Originally Posted by OpenGL ES 1.1 Spec
    3.4.4 Line Multisample Rasterization

    If MULTISAMPLE is enabled, and the value of SAMPLE BUFFERS is one, then lines
    are rasterized using the following algorithm, regardless of whether line antialiasing
    (LINE SMOOTH) is enabled or disabled. Line rasterization produces a fragment for
    each framebuffer pixel ... Coverage bits that correspond to sample points that intersect a retained rectangle
    are 1, other coverage bits are 0. ... Line width range and number of gradations are equivalent to those supported
    for antialiased lines.
    Before you punt, you might just give this a shot. Should be pretty easy to try.
    Last edited by Dark Photon; 04-08-2017 at 05:46 PM.

  5. #5
    Junior Member Newbie
    Join Date
    Feb 2015
    Posts
    15
    Thanks for your time for such a detailed analysis.
    Let me put it into my perspective.
    I expect the anti-aliasing technique to be a hardware driven one, and thus any specific configuration/implementation/upgrade on the software (Mesa) side to achieve that is welcome. Although I understand that these functionalities are tied up with OpenGL, can you point out whether the POINT & LINE SMOOTH techniques are generally achieved by the underlying hardware ? If so, how does it really matter, if I use a framebuffer based EGL or a window based GLX ?
    Now as you pointed out, "Mesa3D's OpenGL ES support is only version 1.1+", may mean that I am using the same, as I have configured it with --enable-gles1 option.
    As for your queries:
    1) I was using exactly the same options as pointed out in the OpenGL wiki.
    2) "Make sure your target framebuffer has an alpha channel allocated" is also a 'YES'.

    But as you pointed out these are "non-uniformly supported and inefficiently-implemented features" let's just look into the other options.
    Though there are lot of other anti-aliasing techniques known, I spoke about MSAA, because that is what I found my chip to support.
    I have referred links/books where they specify that MSAA was introduced from ES 2.0.
    Any which way, I tried out MSAA options with my drawable EGL_SCREEN_BIT_MESA by enabling GL_MULTISAMPLE and configuring EGL_SAMPLE_BUFFERS=1 and EGL_SAMPLES=8 and landed up in eglChooseConfig failure. The only option it was accepting was EGL_SAMPLE_BUFFERS=0 and EGL_SAMPLES=0 (obviously with no results).
    Also a query to these attributes reflected the same. Here's the output to "eglinfo" :-

    Code :
    EGL API version: 1.4
    EGL vendor string: Mesa Project
    EGL version string: 1.4 (Gallium)
    EGL client APIs: OpenGL_ES 
    EGL extensions string:
        EGL_MESA_screen_surface EGL_MESA_drm_display EGL_MESA_drm_image
        EGL_KHR_image_base EGL_KHR_reusable_sync EGL_KHR_fence_sync
        EGL_KHR_surfaceless_gles1 EGL_KHR_surfaceless_gles2
        EGL_KHR_surfaceless_opengl
     
    Configurations:
         bf lv colorbuffer dp st  ms    vis   cav bi  renderable  supported
      id sz  l  r  g  b  a th cl ns b    id   eat nd gl es es2 vg surfaces 
    ---------------------------------------------------------------------
    0x01 32  0  8  8  8  8  0  0  0 0 0x00--      a     y        pb,scrn
    0x02 32  0  8  8  8  8 24  8  0 0 0x00--      a     y        pb,scrn
     
    Number of Screens: 2
     
    Screen 0 Modes:
      id  width height refresh  name
    -----------------------------------------
    0x01  1024    768   60.000  1024x768
    0x02  1680   1050   60.000  1680x1050
    0x03  1280   1024   75.000  1280x1024
    0x04  1280   1024   60.000  1280x1024
    0x05  1152    864   75.000  1152x864
    0x06  1024    768   75.000  1024x768
    0x07  1024    768   60.000  1024x768
    0x08   800    600   75.000  800x600
    0x09   800    600   60.000  800x600
    0x0a   640    480   75.000  640x480
    0x0b   640    480   60.000  640x480
    0x0c   720    400   70.000  720x400
     
    Screen 1 Modes:
      id  width height refresh  name
    -----------------------------------------
    0x11  1024    768   60.000  1024x768
    0x12  1680   1050   60.000  1680x1050
    0x13  1280   1024   75.000  1280x1024
    0x14  1280   1024   60.000  1280x1024
    0x15  1152    864   75.000  1152x864
    0x16  1024    768   75.000  1024x768
    0x17  1024    768   60.000  1024x768
    0x18   800    600   75.000  800x600
    0x19   800    600   60.000  800x600
    0x1a   640    480   75.000  640x480
    0x1b   640    480   60.000  640x480
    0x1c   720    400   70.000  720x400

    Although, I really am in a soup, I am ready to take this on and find out what exactly is lacking in my HW/SW configuration. Also since, the EGL 1.4 is properly in place, I really wonder why the display properties are not supporting to enable Multisample Buffers ?

    Please let me know your take on this. Thanks again.
    Last edited by Dark Photon; 04-10-2017 at 04:33 PM.

  6. #6
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,032
    Quote Originally Posted by muthuveera View Post
    I expect the anti-aliasing technique to be a hardware driven one, and thus any specific configuration/implementation/upgrade on the software (Mesa) side to achieve that is welcome.
    For correctness, I would reword this as: The anti-aliasing technique functionality may be hardware influenced, but it is completely determined by the implementation of the drivers. In particular, the OpenGL GL / GL-ES drivers (provided by Mesa3D in your case) and the windowing system interface drivers (again provided by Mesa3D in your case).

    In other words, regardless of what the hardware can do, you're limited by what the software drivers can do with that hardware. Also consider that your Mesa3D-based drivers were not implemented by the folks who designed and produced the GPU that you're using, so you shouldn't expect them to make as full and complete use of your GPU as the GPU vendor's drivers do.

    Case in point, your available EGL configs when running under Mesa3D:

    Code :
    Configurations:
         bf lv colorbuffer dp st  ms    vis   cav bi  renderable  supported
      id sz  l  r  g  b  a th cl ns b    id   eat nd gl es es2 vg surfaces 
    ---------------------------------------------------------------------
    0x01 32  0  8  8  8  8  0  0  0 0 0x00--      a     y        pb,scrn
    0x02 32  0  8  8  8  8 24  8  0 0 0x00--      a     y        pb,scrn

    Wow. That's interesting. You've only got a choice between RGBA8 with or without a 24-bit depth buffer and 8-bit stencil buffer. No MSAA configs to be found anywhere (as you said). That's pretty ... minimal. I'm positive that you get a much larger set of GLX visuals and FB configs when running under the AMD/ATI GL drivers on Linux.

    As to your Mesa3D setup though, I suspect that you'll get a much better selection of EGL configs if you just rebuild your Mesa3D to support software-only EGL+OpenGL ES. And/or I would try updating your Mesa3D to get a potentially expanded EGL config selection under a) their r600 driver and b) via pure software-only EGL+GLES.

    If you were using OpenGL ES 3.0+, I'd suggest that you (after you tried the previous two and had no success) ditch Mesa3D's EGL implementation on your r600 driver and just do your MSAA rendering inside of OpenGL ES with framebuffer objects (FBOs). GLES 3.0+ supports allocating multisample renderbuffers and textures which you can attach to FBOs to do multisample rendering w/o EGL involvement. But unfortunately you're using ES1.

    ...can you point out whether the POINT & LINE SMOOTH techniques are generally achieved by the underlying hardware ? If so, how does it really matter, if I use a framebuffer based EGL or a window based GLX ?
    I think I explained this above, but same GPU + different drivers = potentially totally different set of features exposed, and those exposed possibly exposed differently.

    POINT_SMOOTH and LINE_SMOOTH in the GLES 1.x spec also left quite a bit up to the actual implementation to decide (see Antialiasing in Section 3.2 Antialiasing in the ES 1.1 spec for more on this). These features were removed from the ES 2.0 spec, so if forward compatibility is important this might suggest it's not worth spending a lot of time on getting these old, obsolete features working for you:

    Quote Originally Posted by OpenGL ES 2.0 Spec with Changes
    Removed references to non-multisample antialiasing in chapter 3, including
    point/line antialiasing in the fourth paragraph of the chapter; all of the old
    “Antialiasing” and “Antialiasing Application” sections 3.2 and 3.9; and the
    description of mixing multisample and smooth rendering in the third para-

    graph of section 3.2.
    This removal also suggests that the underlying support was probably more provided by the software driver than the GPU hardware itself.

    Also since, the EGL 1.4 is properly in place, I really wonder why the display properties are not supporting to enable Multisample Buffers ?
    There's nothing that mandates that every EGL implementation expose every possible feature supported by your hardware. Same with the OpenGL ES implementation.

    This is especially true when they're not implemented by the same company that designed/produced your GPU.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •