Skip to content

Conversation

@abaire abaire force-pushed the fix/implements_lod_bias branch 2 times, most recently from 3ece4e2 to a895ea2 Compare September 18, 2025 19:51
@abaire abaire force-pushed the fix/implements_lod_bias branch from a895ea2 to b8ada79 Compare September 18, 2025 19:52
@Triticum0
Copy link
Collaborator

Seems to improve ground texture quality of Quantum Redshift. Though rather subtle
Masters
xemu-2025-09-18-20-46-58

PR
xemu-2025-09-18-20-59-19

@abaire
Copy link
Contributor Author

abaire commented Sep 18, 2025

@Triticum0 excellent, thanks for testing!

Could you also check Vulkan with the newest build? I don't have access to a VK capable machine at the moment and put in a prospective fix.

@Triticum0
Copy link
Collaborator

Seems to fix Burnout-3-Takedown ground texture quality too.
Masters
xemu-2025-09-18-21-30-56

PR
xemu-2025-09-18-21-31-36

Tested vulkan matches opengl didn't crash and looked identical to opengl.

@Triticum0
Copy link
Collaborator

Also tested crash and burn as well Wreckless The Yakuza Missions Both seem to be unrelated.

@abaire abaire marked this pull request as ready for review September 18, 2025 20:52
@abaire
Copy link
Contributor Author

abaire commented Sep 18, 2025

Thanks! I'll take a look at the traces you added to #2385, we might want to split them into a separate issue if they're due to a novel issue.

@Triticum0
Copy link
Collaborator

Triticum0 commented Sep 18, 2025

Opps actually fixes Crash 'N' Burn floor rendering and tree rendering. Look at outline around far floor textures and outline around 2d tree texture. #1110

Masters
xemu-2025-09-18-22-28-10

PR
xemu-2025-09-18-22-28-29

Doesn't fix railing above the track. only realise other issues where fixed when double checking to get a capture.

Hardware screenshot from loading screen

xemu-2025-09-18-22-32-27 Ingame xemu-2025-09-18-22-32-31

See theirs 5 parts in-game rails but on screenshot there at least double. don't know if its related send capture soon. Found a hardware capture actually occurs on hardware https://www.youtube.com/watch?v=KIHMt-TKgYk

@Triticum0
Copy link
Collaborator

Renderdoc are on this issue if your interested have add new one for the railing issue as I missed it before

@Triticum0
Copy link
Collaborator

Doesn't fix Racing Evoluzione/Apex ground texture issue.

@Triticum0
Copy link
Collaborator

Fixes #2377
Masters
xemu-2025-09-18-23-02-56

PR
xemu-2025-09-18-23-01-37

@Triticum0
Copy link
Collaborator

Triticum0 commented Sep 18, 2025

Fixed metal mesh overhead sign next to Xicat logo rendering incorrectly. on Motor Trend Presents Lotus Challenge.
Masters
xemu-2025-09-18-23-13-47

PR
xemu-2025-09-18-23-14-00

Hopefully why car blue or green could be looked at only happens with no shader cache.

Other Issues in #1228 are unaffected

@abaire
Copy link
Contributor Author

abaire commented Sep 18, 2025

@Triticum0 just to confirm, does this fully resolve #1110 or are there still remaining issues? I don't want to accidentally close out that issue if there is still work to be done.

@Triticum0
Copy link
Collaborator

Triticum0 commented Sep 18, 2025

Create new issue which supersede old issue with remaining issues so you can close it. other issue unrelated so I will move it

@Triticum0
Copy link
Collaborator

Triticum0 commented Sep 18, 2025

Improves the behavior of burnout 2 grass texture. #1161
Master
xemu-2025-09-19-00-14-19

PR
xemu-2025-09-19-00-13-46

No 100% sure if it matches hardware seem behavior present on hardware but not if it the same. need hardware capture to verify. here video where you can see line on hardware https://youtu.be/HGxRSVldAHk?t=333

@abaire Leave it to you judgment where you want to close the issue. the other issues on the pr either occur on hardware or are already fixed so can be closed if you thing the fix sufficient for bug above.

@Triticum0
Copy link
Collaborator

Triticum0 commented Sep 18, 2025

#2437 supersedes #1110 you can close it when it merged to masters.

@abaire
Copy link
Contributor Author

abaire commented Sep 18, 2025

Improves the behavior of burnout 2 grass texture. #1161
@abaire Leave it to you judgment where you want to close the issue. the other issues on the pr either occur on hardware or are already fixed so can be closed if you thing the fix sufficient for bug above.

Does the Z-fighting mentioned not occur anymore? I assumed that bug would need coldhex's #2240 to fix some parts of it. We might need to break that bug up into separate issues, maybe we can just do that after this change is merged and leave off whatever is fixed by LOD biasing.

#2437 supersedes #1110 you can close it when it merged to masters.
Perfect, marked #1110 as fixed by this; thanks!

@Triticum0
Copy link
Collaborator

It hard to see but It also occurs on hardware https://youtu.be/HGxRSVldAHk?t=502 so you can close that too. ask cold-hex about similar issue and he mention it occurred on hardware so in most of my old z-fighting I mentioned weren't valid.

@Triticum0
Copy link
Collaborator

Triticum0 commented Sep 19, 2025

Fixes rendering on distance building looking blurry on Driver: Parallel Lines. you can actually see windows on distance side buildings.
Master
xemu-2025-09-19-12-14-03

PR
xemu-2025-09-19-12-14-21

.minLod = mipmap_en ? MIN(state.min_mipmap_level, state.levels - 1) : 0.0,
.maxLod = mipmap_en ? MIN(state.max_mipmap_level, state.levels - 1) : 0.0,
.mipLodBias = 0.0,
.mipLodBias = convert_lod_bias(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolute value needs to be clamped to device limits (see VkPhysicalDeviceLimits::maxSamplerLodBias)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, I think; will need to see if my change builds on CI since I can't build VK locally right now.

return possibly_dirty;
}

static inline float convert_lod_bias(uint32_t lod_bias)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If implementation is identical between renderers, prefer to have this in common code

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

unsigned int addru = GET_MASK(address, NV_PGRAPH_TEXADDRESS0_ADDRU);
unsigned int addrv = GET_MASK(address, NV_PGRAPH_TEXADDRESS0_ADDRV);
unsigned int addrp = GET_MASK(address, NV_PGRAPH_TEXADDRESS0_ADDRP);
unsigned int lod_bias =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Prefer to group filter params

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

pgraph_texture_mag_filter_gl_map[mag_filter]);
binding->mag_filter = mag_filter;
}
if (lod_bias != binding->lod_bias) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

binding->lod_bias not initialized?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, done.

bool border_color_set;
GLenum gl_target;
GLuint gl_texture;
uint32_t lod_bias;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Prefer to group filter params

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

float lod_bias = pgraph_convert_lod_bias_to_float(
GET_MASK(filter, NV_PGRAPH_TEXFILTER0_MIPMAP_LOD_BIAS));
if (lod_bias > r->device_props.limits.maxSamplerLodBias) {
lod_bias = r->device_props.limits.maxSamplerLodBias;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to also handle negative bias clamp (absolute value must not exceed maxSamplerLodBias)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, misread your comment, sorry!

That said, is it actually necessary to manually clamp these at the application level?

The docs lead me to believe that the driver would handle the clamping, since it ends up being a summation of the bias and the sampling so simply clamping the bias may be insufficient to remain in bounds anyway:

maxSamplerLodBias is the maximum absolute sampler LOD bias. The sum of the mipLodBias member of the [VkSamplerCreateInfo](https://registry.khronos.org/vulkan/specs/latest/man/html/VkSamplerCreateInfo.html) structure and the Bias operand of image sampling operations in shader modules (or 0 if no Bias operand is provided to an image sampling operation) are clamped to the range [-maxSamplerLodBias,+maxSamplerLodBias]. See https://registry.khronos.org/vulkan/specs/latest/html/vkspec.html#samplers-mipLodBias.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it actually necessary

Maybe, maybe not. According to spec: The absolute value of mipLodBias must be less than or equal to VkPhysicalDeviceLimits::maxSamplerLodBias

the driver would handle the clamping

In general, Vulkan drivers are a lot less forgiving. Even when operating fully within spec, they can be problematic. If we are lucky, a case like this would trigger a validation warning and have no other impact, if we are unlucky it results in some random overflow and a crash, so it's best to follow spec guidance when populating struct params.

static inline float pgraph_convert_lod_bias_to_float(uint32_t lod_bias)
{
int sign_extended_bias = lod_bias;
if (lod_bias & (1 << 12)) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this 12th bit have any significant name or is it merely tested to "or in" the subsequent 0x00001FFF const? And whats the significance of that? Fixed point ceiling, because of the final division by 256.0f ? Xemu is not strong in code comments but this looks like a hard to maintain bit of logic of anyone ever needs to revisit this again.

Copy link

@PatrickvL PatrickvL Sep 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mind, it is actually doing sign extension on the 12th bit onwards, assuming the trust contains a 12 bit signed fixed point number (4 integer + 8 fractional bits, in twos complement, a.k.a. Q3.8). Apparently there's no helper function for that yet.

Just 1 thought: the output range is now -8.0 to +7.99609375 which is not exactly 8.0
Would that be any problem?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there are many places where 5.8 fixed point numbers are used and it doesn't seem clearly useful to bother with a more complicated generic sign extended fixed point -> float conversion function.

I also doubt it'd 7.99609375 versus 8 would result in noticeable differences if it actually ends up being materially different from how the nv2a HW handles the 5.8 value. I'd guess there's likely more variance across HW/drivers than that fractional delta in any case.

@Triticum0
Copy link
Collaborator

Fixes #973
Before
170250344-168577d3-2c75-4dcd-9572-f190646678eb

After
xemu-2025-09-20-21-47-49

@Triticum0
Copy link
Collaborator

Fixes #1204
Before
xemu-2022-07-25-23-30-42
After
xemu-2025-09-20-23-49-05

@Triticum0
Copy link
Collaborator

Should Fix #1930 but haven't tested it

@mborgerson mborgerson merged commit 2d26f18 into xemu-project:master Sep 23, 2025
21 checks passed
@mborgerson
Copy link
Member

Thanks!

@Triticum0
Copy link
Collaborator

Did fix #1930

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants