Currently Mesa supports OpenGL 2.1. But some drivers, e.g. intel, support only the old 1.4 version. So, if i use hardware acceleration, i cannot run programs which need OGL 2.0+, but if i use NoAccel option, OGL 2.1 support turns on, and i can run these apps, but this becomes useless since graphics speed is too low. Intel (and, maybe some other) drivers should support main Mesa version of OpenGL, at least accelerate those graphic operations which the hardware is capable of, and do in software the rest, so if the app needs OGL 2.0 and higher version support, it gets it, and at least something gets accelerated.
You fundamentally misunderstand how OpenGL support works in Mesa. If a driver doesn't state that it supports OpenGL x.y, that means it _actually doesn't support it_. Please just close the bug as invalid. I don't want to do it myself.
But why couldn't it fall back to software rendering if it doesn't support some feature?
>You fundamentally misunderstand how OpenGL support works in Mesa. Maybe there is some documentation which would make me understand it properly? I couldn't find it.
Each OpenGL version has a list of mandatory features which must be supported by the GL (graphics library). Of course you could just advertise OpenGL 3.2 support for every hardware driver in Mesa (assuming that the software driver supports all OpenGL 3.2 features) and fall back to SW-rendering as soon as the application uses a features which the hardware doesn't natively support. However that's not how Mesa works. SW-rendering is slow, much slower than HW-accelerated rendering so each driver only advertises a feature-list which it can support (more or less) in hardware. Based on this feature-list the advertised OpenGL version is generated. If the hardware only supports all features that are needed for GL 1.4 but not all features for GL 2.0 -> then you only get version 1.4 advertised. !!! Only if all mandatory features for a given GL version are supported in hardware, then you get the version advertised by the driver. !!! There are of course exceptions, like the ARB_npot support on nvidia Geforce FX cards, but that's how it works in general and also for Mesa. Someone please correct me if I stated something wrong :)
>SW-rendering is slow, much slower than HW-accelerated rendering This shouldn't be the reason for refusing to support any features in the driver. OpenGL is not only used for games. So, in many applications it's not required to be too fast. But, existence of any acceleration is always good. Sometimes one will need to use feature which is not supported by hardware, and it's absolutely inefficient to lose all hardware acceleration (via NoAccel) just to get higher GL version to enable this feature. It might be much faster to use the acceleration which hardware supports while using SW for the features it doesn't. Ideally, SW-fallback to support needed GL version should be an option in driconf, so that if an application doesn't need high GL version, it won't see its support and will stay fast.
You can force software rendering with an env var: LIBGL_ALWAYS_SOFTWARE=1
>You can force software rendering Yes, that's just what i don't want ;) What this bug is about is to have Mesa accelerate everything it (given the hardware) can, and do in software what is can't accelerate.
Listen now, lots and lots of programs will check the extension string to determine whether certain functionality is available. So say you check for GLSL in order to do phong shading but in case it's not there you fall back to ff light. Now we have a problem because that program will see "oh, I have GLSL, let's shade away" and your application will run at horrendously bad speed. In order to fall back intelligently you will face a slightly harder problem. You can't read from textures in VRAM, and VRAM is where we store them to achieve good speed. Falling back would require either constantly migrating textures between VRAM and GART or just keeping them in GART thus taking a serious performance hit on everything that samples from textures. Now close your bug. I'm tired of getting e-mails of you acting smart.
(In reply to comment #7) > What this bug is about is to have Mesa accelerate everything it (given the > hardware) can, and do in software what is can't accelerate. > Not worth the trouble, read what Joakim wrote. With this approach you probably end up with a performance worse than pure software rendering. There might be some corner cases where the "mixed-model" approach might be slightly faster, but again: it's not worth the trouble. If you just need all fancy GL features and you don't care about performance -> use the software renderer.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.