Skip to content

Avogadro, OpenGL and Display Bugs

Posted by Marcus D. Hanwell on

Before last summer I had never really done any OpenGL programming. Now I feel like I know a reasonable amount but certainly still have a lot to learn. I have an Acer Ferrari laptop with an ATI Radeon X700 discrete graphics card in it. I was using the proprietary driver for a while but it was so unstable it just wasn't worth using. I was hopeful after reading about AMD opening up the specs so that good 3D support can be added to the open source driver.

Avogadro showing a filled surface with incorrect colouring on ATI open source driverAvogadro showing a surface with correct colouring on ATI open source driver

I have to say on the whole the 3D support has been getting better and better for the r300 chipset. I cannot enable the desktop effects in KDE 4.1 trunk without losing my OpenGL apps though. As you can see in the above screen shots filled surfaces also do not work. For some reason the colouring of the surface is incorrect, i.e. the colour is never changed. I am running the latest git sources of xorg, the ati drivers, x11-drm, mesa etc, thanks to Donald Berkholz. Avogadro seems hit File r300_render.c function r300Fallback line 360, Software fallback:ctx->RenderMode != GL_RENDER every time too.

There is an open bug report that appears to be describing the same situation. I do wonder if it is possible that our OpenGL code could be improved to avoid this bug. I would love any tips on ensuring our OpenGL code is as compatible as possible. The surface rendering works correctly on all other platforms (Linux, Mac, Windows) and with other drivers as far as I know.

We also have an open bug report where Avogadro segfaults on Linux systems using the savage driver. This seems to be a consistent problem. I am afraid I do not have the hardware to test further, I have added further debug output to our initialisation routines - Avogadro crashes very early on. Again, any ideas on how I might fix this bug or at least exit gracefully would be great. Backtraces may help to at least see what functions are called before the crash but this might just be a driver bug.

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

Jos on :

JosI've got a savage, and I can tell you it is certainly a driver bug : it has so many problems...

Only switching from 1024x768 to a full screen 640x480 OpenGL application makes it crash, since the new randr code.

Marcus D. Hanwell on :

Marcus D. HanwellIt is good to get some feedback. I didn't know if the driver was so broken OpenGL is basically not possible right now or if it was some calls we were making that could be avoided (at least conditionally). I have hit a few OpenGL bugs but these two have been the toughest to find a good solution or workaround for.

Donnie Berkholz on :

Donnie BerkholzThanks for the props! Please call me Donnie though. =)

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA 1CAPTCHA 2CAPTCHA 3CAPTCHA 4CAPTCHA 5


You can use [geshi lang=lang_name [,ln={y|n}]][/geshi] tags to embed source code snippets.