Soft Shadows do not work on Intel IvyBridge graphics with Mesa.

[aFoxNamedMorris]

Hello. I have been enjoying the quality and smoothness of this port. It's so fast! However, I cannot activate soft shadows. Whether I use the CVAR or the options menu, it immediately resets to false.

Here is the output of 'glxinfo': http://pastebin.com/mVgtL9ZQ

I compiled RBDoom3BFG from source, and it runs, but all of the Mesa-centric code causes errors in the console. I believe is the cause of the lack of soft-shadows.

Any help would be greatly appreciated.

[BielBdeLuna]

GL version is 3.0 and RBDoom3BFG needs GLversion 3.2, the mesa drivers still lack some improvement to reach 3.2 (in a compat profile, because in core profile it's already at 3.3 ) I don't know why but Intel seems to have abandoned the compat profile, they keep working on core profile items only.

@RobertBeckebans does RBDoom3BFG needs the compat profile? would it be possible to just use the extensions of core profile?

[aFoxNamedMorris]

So, until Mesa gets more up to date, I'm SOL on Soft Shadows?

[BielBdeLuna]

yep, you're SOL on that. :)

[aFoxNamedMorris]

At least for now. At least I know I was right and not crazy. XD Peace of mind. And hey, at least the game runs at 60FPS with high resolution textures and models! :D

[RobertBeckebans]

Last time I tried shadow mapping on Intel was 2 years ago and It was like 20 seconds for 1 damn frame.

[RobertBeckebans]

@BielBdeLuna Core profile should be enough if you get one :) I simply set r_useShadowMapping to 0 if there is a "Intel" in the driver name.

[aFoxNamedMorris]

I'm using the bleeding edge Mesa drivers. A lot has happened in the last couple of years. How would I go about disabling that bit so I can test it?

EDIT: Managed to get rid of all the GL errors that kept showing up during startup. Edited out the Intel workarounds lines in the render init code. Still can't find the blacklist bit.

EDIT2: Found it! Gonna test it out. WOO!

EDIT3: So, I did some testing, both with and without the Hi Def/Trentphrozo mods. Framerate was sporadic. Fluctuated between 25-52FPS, and dropping to 15FPS in specific small areas. I managed to stay above 30FPS by lowering the soft shadow quality values to bare minimum and only using stock assets.

[BielBdeLuna]

2 years ago mesa wasn't OpenGL3.2 ready even at core profile in Linux maybe we could have a lower quality shadows (without being soft)

[aFoxNamedMorris]

The default stencil shadows already work great... They look horrid, but they work. So, are you proposing a shadow type that isn't the current soft shadow method, but still better than the vanilla hard shadows? Scariest thing is that with the Linux 4.2.3 kernel, Oibaf PPA Mesa... I can run the game with BFG Hi Def mod and Phrozo effects... and still get a solid 60FPS. O.o Just wish It didn't mean using these ugly vanilla shadows.

[RobertBeckebans]

What soft shadow settings have you changed? That sounds good

[BielBdeLuna]

@aFoxNamedMorris I meant non soft shadows but still shadow mapping. like old shadow mapping so at least we have something beyond the stencil shadow.

[aFoxNamedMorris]

r_shadowMapImageSize 128 r_shadowMapLodBias 1 r_shadowMapSamples 1

on a 1366x768 monitor, that doesn't look too bad, but it still screws around with the frame rate. In Mars City, for example, I was getting ~30-45FPS in the starting area, ~7-10 in the bio scan, and ~15-20 in the facility itself, with areas going all the way up to ~40-55. Like I said. Really odd framerate.

[BielBdeLuna]

@aFoxNamedMorris can you post your change here I'd like to see it in a Sandy Bridge system ( a generation before than yours )

[aFoxNamedMorris]

The code edit I used to un-blacklist Intel?

[BielBdeLuna]

yes

[aFoxNamedMorris]

neo/renderer/RenderSystem.cpp

Comment out Line 316 and recompile.

Also, to fix the GL errors that occur during startup, you can edit neo/renderer/RenderSystem_init.cpp at line 450 so it looks like this:

// GL_ARB_sync
glConfig.syncAvailable = GLEW_ARB_sync; //&&
                         // as of 5/24/2012 (driver version 15.26.12.64.2761) sync objects
                         // do not appear to work for the Intel HD 4000 graphics
                             //( glConfig.vendor != VENDOR_INTEL || r_skipIntelWorkarounds.GetBool() );

Hope this helps.

[BielBdeLuna]

ok thanks I'll try it

[aFoxNamedMorris]

Oh crap! Remember to set the framerate to 120 in the settings menu. It helped me get a more stable 60FPS when using the default shadows. Went from 37-60FPS to 57-60FPS.

[BielBdeLuna]

ok

[aFoxNamedMorris]

I wonder how these changes would work when running on Broadwell or Iris?

[BielBdeLuna]

I get a halved fps from stencil shadows: 60 to 8 with a Sandy Bridge from 2011 at 720p resolution. I wonder could we get a r_useSoftShadows? maybe use shadow mapping for a really simple method of shadow mapping for slow computers and yet still be able use the current soft shadows for more powerful computers.

[aFoxNamedMorris]

A CVAR would be helpful.

r_ShadowType -value-

0 = Stencil 1 = Shadow Mapping 2 = Soft Shadows

[RobertBeckebans]

r_shadowMapSamples has no effect since the number of samples is hardcoded in the shader and anything below 12 would look like crap.

However r_shadowMapImageSize 128 is extreme but good to reduce the fillrate and r_shadowMapLodBias 1 selects a lower resolution target at distance.

[aFoxNamedMorris]

Ah. Thanks for the heads-up on that. Well, at least the other two options seem to work. Weird that if I set the samples to 4 or 16 when the image size is reduced, the shadows wiggle like old MD2 animations...

[BielBdeLuna]

I think this might shed some light with this damn issue: since OpenGL3.1 mesa only implements core context:

http://cgit.freedesktop.org/mesa/mesa/plain/docs/GL3.txt

in the first lines it explains it.

so compatibility context won't be implemented within Mesa.

does RBDoom3BFG use any extension from the compatibility context? if not could we make it so it only needs OpenGL3.2 core context? without it all Linux users would be locked at OpenGL3.0 while their hardware and hardware drivers might be more capable than OpenGL3.0!

[aFoxNamedMorris]

Or you could just use nVidia or AMD. Intel works... that's not the issue. I got it working. The issue is speed. It's uber slow for my taste.

[BielBdeLuna]

what? what is slow? you mean the proprietary drivers?

[aFoxNamedMorris]

No, the soft shadows on Intel Ivybridge graphics, even with the soft shadow at lowest possible settings. It's not a huge deal, as almost nobody would attempt it. I just wanted the option available. Likely, Broadwell or Iris graphics would handle them just fine.

[ghost]

@aFoxNamedMorris I've used custom open source drivers before on Windows with older Intel graphics chips to play games like Bioshock, maybe look around to see if there is a custom driver for your chipset. The Driver I used was for Windows, the BNA driver, not sure if there is one for Linux. You could also try a custom kernel for Linux aimed at gaming like the liquorix kernel, I've use it before on Arch Linux, even got more FPS out of it.

[sheepdestroyer]

Mesa will not have Compat context, only Core. And it's not only Intel concerned here : free ADM an Nvidia drivers too, VC4 (Raspberry), ARM, Qualcom, etc... @aFoxNamedMorris Dismissing the reliance on Compat context instead of Core with "buy AMD" seems a bit shortsighted...

[aFoxNamedMorris]

@sheepdestroyer Intel graphics older than Broadwell simply cannot handle the soft shadow effect, regardless of any custom kernel, driver, hack, or what-have-you. Also I did not single out AMD. I said that nVidia and AMD graphics cards are a sure-fire way to make sure the effect works well. Realistically speaking, integrated anything is far weaker than a discreet graphics card. Not trying to be rude; I am however trying to be realistic. Until Vulkan and DX12 are mainstream and there comes a driver for Intel integrated graphics, and games have support for such APIs, certain graphical functions will be far too taxing for the hardware.

[BielBdeLuna]

my Sandy Bridge i52450M can handle soft shadows, albeit RBDoom3BFG runs at (12-10) fps, it's up to me to decide if I wanna keep playing like this, at least as development computer, it serves me to see the shadows that I loose if I go stencil.

Sandy Bridge is the first generation of GPU/CPUs form Intel that can handle OpenGL3.2 ( at core profile ) the minimum required by RBDoom3BFG, take a look here: http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html

We haven't seen yet anything from Vulkan, we can be sure it won't behave differently per hardware vendor even if the idea is that it won't have any difference.

it costs nothing to leave the option there, you might want to offer an explanation for the possible slowdowns if you use mesa drivers, but that should be all the hassle.

but I wonder what other possibilities could it bring to have RBDoom3BFG check for core instead of compat (if it can be implemented) now that the mesa drivers are about to reach OpenGL4.

[aFoxNamedMorris]

Yes the shadows "function" on Sandy/IvyBridge. You and I are proof of that. But most people wouldn't call 10-12FPS "handling". That's choppy, and not too healthy for the hardware. I can play a game and beat it at 15FPS, but it's a slow, difficult, and often irritating chore. I can't enjoy a game at anything less than 30FPS. As for the core profiles, you're preaching to the choir. I've been keeping up with Mesa's i965 driver since 2011. I think I get it. :) I use the latest bleeding edge drivers from the Oibaf PPA, and I use profile overrides all the time for games that need them.

Vulkan? There have been several performance demos at conventions and conferences all year. That's hardly "nothing". As for why we haven't seen any drivers, hands on demos, or other things like that, it's because the spec has not yet been made public. It would be illegal for a company or software group to release drivers, example programs, or any sort of demo program to the public before Khronos Group gives the greenlight and lifts the NDA.

Patience, Grasshopper.

It's your life, your computer. You can do as you wish, and have your own tastes, of course. But remember, just because something works or is pretty doesn't mean it's a good idea to consistently use it. Just use your own discretion, and try to be careful.

EDIT: It's worth noting that the soft shadows slowness on Intel graphics has less to do with drivers, and more to do with the hardware itself. Sandy/IvyBridge only has 512MB of VRAM. That's simply not enough to process HD textures, HD models, and soft shadows. You need a minimum of 1GB of VRAM to safely use all of that under OpenGL. Vulkan may help, but the hardware will always be a limiting factor.

[BielBdeLuna]

if you only want to play Doom3BFG you're right, but if you want to do anything with RBDoom3BFG engine, then you're far better off with it on, specially if it involves all the major hardware vendors that might use the mesa drivers, as it currently does.

try to do a flourished tree with stencil shadows and you'll see.

[aFoxNamedMorris]

I'd rather deal with ugly shadows than overheating my laptop and getting a framerate that makes the game unplayable. And IMHO bad framerate is uglier than hard-edged shadows. I'll take performance over aesthetics any day.

[DanielGibson]

FYI: most of your discussion is totally pointless :-P

I agree that it should be possible to enable (and disable) soft shadows with any GPU (as long as it supports the needed OpenGL version/extension). But I don't see a point in discussing if people with certain Intel GPUs should actually do it or not - it should be their own choice :-)

[aFoxNamedMorris]

You know... you're right. Right or wrong is not relevant here. Agree to disagree, live our lives. Done and done, my good sirah.

[ghost]

The soft shadows breaks on Nvidia cards as well, some times when I compile I get all the textures darkened to the point of black when soft shadows is enabled, most of the time a 32bit build works, for 64bit no luck so far.

[RobertBeckebans]

Guys this is solved with the latest master. Closing ...