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…
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:
- the specific AMD GPU model,
- the GPU driver vendor and version,
- the OS,
- the windowing system library, and
- 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.
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.
[QUOTE=muthuveera;1286634]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
[/QUOTE]
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:
Per the OpenGL ES 1.0 spec:
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:
Before you punt, you might just give this a shot. Should be pretty easy to try.
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:
- I was using exactly the same options as pointed out in the OpenGL wiki.
- “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” :-
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.
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:
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:
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.
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.