- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is a continuation from https://community.intel.com/t5/Developing-Games-on-Intel/Driver-level-bugs-causing-issues-in-Minecraft-amp-OpenGL-shaders/td-p/1664368 which will be split into 3 separate reports.
Link to the tracking issue on Sodium's github https://github.com/CaffeineMC/sodium/issues/3004
The frame persentation layer in the Xe-HPG driver is busted. Frames will present extremely erratically. This manifests in the game's motion appearing jittery, despite no frametime spikes being present to explain the jitter. The workaround is to increase render ahead limit to 4 or more and cap the framerate to somewhere below the average, which still doesn't solve the issue entirely.
Video of the issue: https://drive.google.com/file/d/1VsygjDYucoz82VyD47mD38dcq22nVkb_/view?usp=sharing
To observe the issue these criteria need to be met
- The framerate mustn't be the in the hundreds. So you either need to run shaders or have a very high render distance in an intensive scene.
- The framerate mustn't be capped below the uncapped average framerate.
- Render Ahead Limit musn't be set to 4 or higher.
Even after increasing the render ahead limit the frame presentation appears to be somewhat funky especially during lag spikes.
Reproduction Steps
Preparation:
- Install Iris & Sodium for 1.21.4 : https://github.com/IrisShaders/Iris/blob/multiloader-new/docs/guide.md
- Unpack the shaderpacks.zip inside the (...)\AppData\Roaming\.minecraft folder
- Go into options>video settings>shaderpacks and select "complementary unbound 5.4 + euphoria patches 1.5.2"
- Press apply
Reproduction
These settings concide with the performance of my B580. I'm bringing the FPS to around 100. On older cards you may not need to set render distance to such high value to achieve this FPS.
- Enable the provided shaders to lower your framerate
- Create a new world
- Set render distance to 32
- It is advised to turn off view bobbing
- Fly around in a circle while rotating your camera
If you go to "options>video settings>advanced>render ahead limit" and change that to 4 or a higher value the issue will be greately alleviated.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@karen_intel the developer of sodium said they'll respond if intel (presumably meaning you) responds to this post, as currently there is simply nothing for them to respond to. So like I suppose give them something to go off and you can continue from there.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey @djmrFunnyMan thanks for opening the thread so the dev can see.
As I mentioned before, we need to isolate the issue in a homebrew code (raw code focusing on the issue) to do some testing on our end with the code, debug, root cause the issue and report it internally.
Finished products require an NDA which we cannot handle here and as we don't need access to the whole code, we require the isolation of the problematic shader in a small piece of code.
Thank you. Hope they reply soon
Karen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, I'm the developer of the aforementioned project.
The source code for the project is located here and is provided under a source-available license: https://github.com/CaffeineMC/Sodium
There is not a specific shader involved here, as it is a frame presentation issue and happens regardless of what shaders are actively being rendered with. Specifically, the frames that are scanned out to the monitor may appear out-of-order and/or have significant judder, despite the fact that the application is maintaining a high frame rate and not modifying frame presentation in any manner.
My only guess as to what is causing the problem in our code is the fact that we insert one semaphore right after the buffer swap (see here), insert it into a deque, and then await the oldest semaphore if there are more than 3 outstanding frames in-flight to the driver. In effect, this creates a "frame render ahead" limit. This is required for our application since we don't want an unlimited number of in-flight memory transfers from CPU->GPU to be queued, like most games.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey @JellySquid thanks a lot for your explanation
These pointers will come in handy when debugging this behavior
I'll reach out to you if there's something I need help with
@djmrFunnyMan I will proceed to triage this case
Any update I'll let you both know here
Karen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page