WineHQ Bugzilla – Bug 35624 – 3Dmark 2001 SE: Broken "Fill Rate (Multi-Texturing)" test

Bugzilla

Last modified: 2014-03-07 14:13:03 UTC

3Dmark 2001 SE: Broken "Fill Rate (Multi-Texturing)" test

Bug 35624 - 3Dmark 2001 SE: Broken "Fill Rate (Multi-Texturing)" test


Summary:	3Dmark 2001 SE: Broken "Fill Rate (Multi-Texturing)" test

Status:	CLOSED FIXED

AppDB:	Show Apps affected by this bug
Product:	Wine
Classification:	Unclassified
Component:	d3d
Version:	1.6-rc2
Hardware:	x86-64 Linux

Importance:	P2 normal
Target Milestone:	---
Assigned To:	Mr. Bugs

URL:	http://www.futuremark.com/benchmarks/...
Keywords:	download, patch, regression

Depends on:
Blocks:
	Show dependency tree

Reported:	2014-02-19 06:19 UTC by Wylda
Modified:	2014-03-07 14:13 UTC (History)
CC List:	1 user (show)

See Also:
Regression SHA1:	ffc9f535eb7817ea4cd0d0657471e61a9813debd
Fixed by SHA1:	c1032e977bb9f850e3aea28dd79e3d7c2244cd6c
Distribution:	---
Staged patchset:

Attachments
patch (1.87 KB, patch) 2014-02-25 05:00 UTC, Henri Verbeet	Details \| Diff
View All Add an attachment (back traces, logs, proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Wylda 2014-02-19 06:19:39 UTC

All the test are displayed correctly except "Fill Rate (Multi-Texturing)". Fast way to reproduce click "Change" (under Selected Tests) -> (tab) "Custom" -> Clear -> choose "Fill Rate (Multi-Texturing)" -> click "Benchmark".

Currently the wine lower than 1.7.8 can't be configured&compiled on Debian Jessie due to newer libraries. After backporting pathces for freetype, x11, lcsm2 i was able to make wine happy with configure/make down to 1.7.0/1.6.0. Anyway i endup with non-vannila wine.

If anyone is able to make the regression test, go ahead. It will take me some time to prepare another machine with Debian Wheezy for regression testing below wine-1.7.8.

Comment 1 Henri Verbeet 2014-02-19 11:35:29 UTC

For what it's worth, it seems to render correctly here. In what way is it broken?

Comment 2 Wylda 2014-02-19 14:42:31 UTC

Hi Henri, as that bad-case screenshot is a noisy, thus bigger, i could not attach them here. For sure, i did not reduce the resolution nor used JPEG lossy-compression. Screen shots taken from wine-1.7.12 & nvidia v319.82.


here is a Single-Texturing Fill Rate test (GOOD):
https://www.dropbox.com/s/dv3mmqfnyebzekv/ok_fill_rate_single_texturing.png

Multi-Texturing Fill Rate test (BAD):
https://www.dropbox.com/s/mth0q76t3jvb8z1/bad_fill_rate_multi_texturing.png

Comment 3 Henri Verbeet 2014-02-19 15:00:12 UTC

It looks like the good screenshot for me (r600g, AMD CEDAR), so I guess there could be a driver specific component to this. Unfortunately that also means I can't help much with the bisect.

Comment 4 Wylda 2014-02-19 15:24:14 UTC

Sorry, i don't know if i undrestand that correctly. On your PC, you see the Multi-Texturing the same as me and you consider it as a correct screenshot?

For sure i made a WinXP MultiTexture screenshot:

https://www.dropbox.com/s/fcijsm30s0unj2a/ok_fill_rate_multi_texturing_winxp.png

Now i tried latest git wine-1.7.12-213-gb0b6728 and 32bit only wine version (not wow64), but the same result... I already prepared parition for older Debian and i'm going to install it on the same HW for regression testing. Based on AppDB it was OK on Dec 18 2010 & wine-1.3.9.

Comment 5 Henri Verbeet 2014-02-19 15:31:54 UTC

(In reply to Wylda from comment #4)
> Sorry, i don't know if i undrestand that correctly. On your PC, you see the
> Multi-Texturing the same as me and you consider it as a correct screenshot?
> 
No, it looks like the XP screenshot for me. Your "BAD" screenshot does look clearly broken.

Comment 6 Wylda 2014-02-19 18:45:16 UTC

It is caused by wine-1.6-rc1-64-gffc9f53:

ffc9f535eb7817ea4cd0d0657471e61a9813debd is the first bad commit
commit ffc9f535eb7817ea4cd0d0657471e61a9813debd
Author: Henri Verbeet <hverbeet@codeweavers.com>
Date:   Fri Jun 14 09:07:12 2013 +0200

    wined3d: Handle pre-transformed vertices in the GLSL vertex pipe.

    This also avoids a fallback to drawStridedSlow().



Verified by revert. Is any trace/debug channel needed?

Comment 7 Wylda 2014-02-20 01:24:40 UTC

In advance...
https://www.dropbox.com/s/q5ebbm7fierwvr8/3dmark_logs.tar.bz2

Comment 8 Henri Verbeet 2014-02-25 05:00:18 UTC

Created attachment 47635 [details]
patch

I think the attached patch should help.

It looks like this is NVIDIA specific, and essentially the same issue as bug 32485. When GL_MAP_INVALIDATE_BUFFER_BIT is set, the r600g driver only creates a new buffer if the current one is busy, while it seems the NVIDIA driver always does that. There's probably something to be said for both approaches. This didn't show up before commit ffc9f535eb7817ea4cd0d0657471e61a9813debd because we ended up in drawStridedSlow(), and the buffers would stay on the CPU.

Comment 9 Wylda 2014-02-26 00:33:24 UTC

(In reply to Henri Verbeet from comment #8)
> 
> I think the attached patch should help.
> 

Sure thing, the patch fixes the problem :) Many thanks Henri.

Comment 10 Henri Verbeet 2014-03-04 16:17:27 UTC

Should be fixed by commit c1032e977bb9f850e3aea28dd79e3d7c2244cd6c.

Comment 11 Alexandre Julliard 2014-03-07 14:13:03 UTC

Closing bugs fixed in 1.7.14.