Rebase for 3.4
Closed this issue · 56 comments
Since i dont really wanna figure out how to make pull requests from a forked repo, i am attaching the patches that i rebased to apply on wine-staging-3.4
Patchset applies before rebasing with a few "offsets" warnings and 1 "fuzz" in 0002-wined3d-Add-support-for-backing-dynamic-wined3d_buff.patch - texture.c
Anyway, cleaned up, rebased and applies without errors... use them if you like :)
0001-wined3d-Initial-implementation-of-a-persistent-mappe.patch.gz
0002-wined3d-Add-support-for-backing-dynamic-wined3d_buff.patch.gz
0003-wined3d-Use-ARB_multi_bind-to-speed-up-UBO-updates.patch.gz
0007-wined3d-Avoid-freeing-persistent-buffer-heap-element.patch.gz
0008-wined3d-Add-DISABLE_PBA-envvar-some-PBA-cleanup.patch.gz
assuming your staging patched branch is called staging-3.4
and wine-pba is in ../
git am --3way ../wine-pba/patches/00*
git format-patch staging-3.4
edit: just for fun, did same on wine-3.4-devel
with that just have to do
git rm dlls/wined3d-csmt/Makefile.in;git am --continue
when it complains
are those the only ones we need, do we delete the others, before applying the patch, or are the others still fine as is?
@SteveEbey73742 no need for ANY of the patches
use the original patches in wine-pba via git am --3way as described in my earlier post *
see git am --help for more info about that
- no need to do the git format-patch ,
@SteveEbey73742 Those are the changed patches, the others stay as they are. Total 9 patches.
Was mostly meant for @acomminos to lighten his load, and not something one should have to do or use :) Yeah, the correct way would be to fork and then do some git magic to push those changes back, to this repo for review.. but i guess im a n00b :)
his patches are meant to apply after staging. that being said, the current patches apply to staging 3.4 cleanly (im currently running a staging 3.4 + pba + g9 build)
@GloriousEggroll , when i do my build, I get the following, when I apply pba.
> error: patch failed: dlls/wined3d/texture.c:2513
> error: dlls/wined3d/texture.c: patch does not apply
>
can i ignore the message, and compile?
@SteveEbey73742 , no , not really.
Ok, let us start again
checkout a clean staging 3.4 branch ( wine-3.4 patched with wine-staging v3.4 )
ok, now let us branch off that
git checkout -b staging-3.4-PBA
I assume wine-pba lives in ../wine-pba
git am --3way ../wine-pba/patches/000*
that should do it, the 3way will perform git magic and fix the merge conflict
@GloriousEggroll "Cleanly but with offset information".
@FireRat Sure, but having a patchset rebased still beats doing that for most people. I had no clue you could checkout branches, and do git am --3way to patch vs. just patch :)
:)
@SveSop , been a long time since I used git, slowly coming back to me
the am is good, and it keeps the commit msgs, and author
@FireRat , tried it as you describe, following is the end result.
error: sha1 information is lacking or useless (dlls/wined3d-csmt/Makefile.in).
error: could not build fake ancestor
Patch failed at 0001 wined3d: Initial implementation of a persistent mapped buffer allocator.
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
not sure what to do now, going to wait to see if the author actually does a rebase, or might try some of the other suggestions, when I have more time.
@SteveEbey73742
it looks like you are trying to apply PBA to devel , i.e. without staging patches
if that is what you want to do, then
git rm dlls/wined3d-csmt/Makefile.in
git am --continue
else, do git am --abort and apply staging patches
@FireRat , Shown here is the script I use to build wine, to ensure I get a clean build. I took the modified patches from @SveSop and commented out the wine pba download and your 3way, and it applied cleanly. going to build and see what happens.
rm -fr wine
rm -fr wine-staging
#rm -fr wine-pba
git clone git://source.winehq.org/git/wine.git
git clone https://github.com/wine-staging/wine-staging.git
#git clone https://github.com/acomminos/wine-pba.git
cd wine-staging
./patches/patchinstall.sh DESTDIR="../wine" --all
cd ../wine
git apply ../wine-pba/patches/000*
#git am --3way ../wine-pba/patches/000*
@SteveEbey73742 There is no lack of ideas or stuff you "can" do when popping in to any linux forum :)
So.. here is my "howto wine-staging w/pba patches for dummies"
- Download wine-3.4.tar.xf from here: https://dl.winehq.org/wine/source/3.x/wine-3.4.tar.xz
- Download wine-staging-3.4.tar.gz from here: https://github.com/wine-staging/wine-staging/archive/v3.4.tar.gz
- Make a folder somewhere in your home directory or whatever with write access.
- Copy both those files in that folder and do:
tar xf wine-3.4.tar.xz && tar -zxvf wine-staging-3.4.tar.gz cd wine-staging-3.4/patches./patchinstall DESTDIR='../../wine-3.4' --allcd ../..git clone https://github.com/acomminos/wine-pba.gitcd wine-pba/patchesnano pba.sh- Paste the following:
DIR=$(dirname $0)
for each in $DIR/*.patch
do
patch -p1 < $each
done
echo Done patching PBA!
Exit and save.
12. chmod u+x pba.sh
13. cd ../../wine-3.4
14. ../wine-pba/patches/pba.sh
15. Follow regular guide to compile wine for your distro
If that fails... I dont know what to say :)
Hehe.. well.. just as i pressed the "comment" button :D
Now.. to the fun part..
I have a bit of a quarrel with Henri Verbeet about the vsync patch and the changes in wine-3.4.. as such that i did not get vsync disabled with staging patches.
From what he says, i am not sure how to interpret this, as it might seem as there is something wrong at my part.. so it will be interesting to see if anyone else have problems disabling vsync with wine-staging-3.4. This is unrelated to "PBA" tho, so perhaps not relevant for this thread. (And PBA patches does not affect this afaik)
hmm, @SveSop
bash: nano: command not found
can I use vim ?
lol
anyway, if you are going to get someone to cpoy pasta something
cat > pba.sh << 'EOF'
DIR=$(dirname $0)
for each in $DIR/*.patch
do
patch -p1 < $each
done
echo Done patching PBA!
EOF
but patch -p1 < *.patch
does the same, so
alias pba='patch -p1 < $1*.patch'
just make certain you have trailing / on a dir
pba ~/randompatches/
@SteveEbey73742 , ok , I shall have to download the patches, because they should have the same problem ( wined3d-csmt missing is a problem with what is being patched, not the patch ! )
Hehe, yeah, im sure there are just as many ways to do something as there are bits in all the worlds combined storage space....
The awesome part is that there is really no "right" or "wrong" way to make a script really.. Its like saying "Hey, the BEST color is ofc GREEN!" :)
@SteveEbey73742
no idea what is wrong, regardless of which patch method is used, it should still complain/fail
if a file is missing, a file is missing ..
git log -p dlls/wined3d-csmt
@SveSop , do you really use nano?
vim is a learing curve, but well worth it .. I really wish I knew more vim..
here's how I do it. just look at prepare() section in PKGBUILD:
https://github.com/GloriousEggroll/ge-wine
in short:
git clone http://github.com/wine-mirror/wine
git clone http://github.com/wine-staging/wine-staging
git clone http://github.com/acomminos/wine-pba
cd wine
#msg2 'Changing wine HEAD to the wine-staging base commit...'
git checkout "$(../wine-staging/patches/patchinstall.sh --upstream-commit)"
# fix path of opencl headers
sed 's|OpenCL/opencl.h|CL/opencl.h|g' -i configure*
# apply staging patches
../wine-staging/patches/patchinstall.sh --all
# add pba patches
for _f in $(ls ../wine-pba/patches); do patch -Np1 -i ../wine-pba/patches/$_f; done
I'll see about writing some stuff down
we can then have a wiki war
atm I'm thinking about backporting pba to wine-staging-2.0 , because apparently people like that one
so no idea how long
IT WORKED!!!!! I have an 3.4 pba with vsync control. so in summary, used the patched pba that @SveSop fixed (thanks), used my script file, to get latest git pulls from devel and staging (yea, me), and applied the pba (brilliant work @acomminos ) and the vsync fix from @SveSop (thanks again). Who needs windoze when I can find so many brilliant people.
Anyone that wants the patched, vsync, pba source code for 3.4, send me a message. too big to attach to this comment. around 232mb in compress form.
@GloriousEggroll
personally, I would do something like this
git checkout $(../wine-staging/patches/patchinstall.sh --upstream-commit) && \
../wine-staging/patches/patchinstall.sh --all --backend=git-am || \
echo "oops, looks like we are missing the commit staging expects"
also, $(ls ../wine-pba/patches) is bad,
and not needed, bash is smart and will glob
it will deal with whitespace, which your subshell won't ( put some spaces in the filename and try it out )
for _f in ../wine-pba/patches/00*.patch;do
echo "applying ${_f##*/}"
patch -Np1 -i "${_f}" && continue
echo "oh nooooo.. ${_f##*/} broke somehow
break
done
Edit, add a break on fail
And just for lulz i set up a "patched" github.
https://github.com/SveSop/wine-staging-pba-patched
Under "releases" it is wine-staging-pba-3.3 and wine-staging-pba-3.4 . This is release with untouched "staging".
If you just clone the "Master" branch, i have added the vsync hack to get vsync working with wine-staging-pba-3.4. With https://github.com/SveSop/wine-staging-pba-patched/commit/47404f07dc4f56e1eae2785eeee71be56c8fd9d0
Saw the staging repo had new updates, so used my bash script, with the patched files from here, with latest devel and staging applied, pba went on, changed line 634 in swapchain from 1 to 0 for vsync. Build was perfect, so running wine-3.4-57-gcfb67712ce (Staging) with no problems.
What is this about vsync? I'm trying to search the interwebz for it, but my search skills aren't all there it seems. Is it related to why my framerate seems locked to 60 even though I have vsync disabled in all games?
@Goldpaw, yes the vsync is broke, in that it is set on all the time, regardless of your settings. if you edit the file wine/dlls/wined3d/swapchain.c and find
swap_interval = swapchain->desc.swap_interval > 4 ? 1 : swapchain->desc.swap_interval;
and change the 1 to 0, after you apply patches and pba, but before you run configure, you can fix the vsync problem. something between wine devel 3.3 and wine devel 3.4 changed and broke the ability to enable and disable vsync. this will give that ability back.
@Goldpaw
Probably, but I havn't followed the logic in wine.
let us first confirm wined3d is the reason for the cap
run glxgears
if fps capped at 60 then vsync is on system wide
nvidia or amd?
nvidia-settings ---> X Screen ---> opengl settings
- sync to vblank
glxgears should no longer be capped
amd might not be so easy
[[ -e ~/.drirc ]] && cat ~/.drirc || (
cat > ~/.drirc << EOF
<driconf>
<device screen="0" driver="dri2">
<application name="Default">
<option name="vblank_mode" value="0" />
</application>
</device>
</driconf>
EOF
echo wrote ~/.drirc;cat ~/.drirc )
try glxgears again, if you are still capped delete ~/.drirc and hunt the great elibrary in the cloud
but may be start here
just for fun, install wglgears with winetricks
WINEPREFIX=~/.somewinebottle winetricks wglgears \
&& WINEPREFIX=~/.somewinebottle wine \
"$(find ~/.somewinebottle/drive_c -name wglgears.exe)"
in separate term glxgears -geometry 300x300+300+0
infact, do that with both vsync on and off, might give you a reason to stick with it on
Edit
- note that wglgears does not use wined3d, once you have vsync off you still may see the 60fps cap in wined3d
@SteveEbey73742 it was e318f8c825719ceb68bcc0b83142256bec3b8346
git log -p e318f8c825 -1 -- dlls/wined3d/swapchain.c
DXVK does not use Wined3d to set up swapchain i think, as it uses dxgi.dll and d3d11.dll... No problems with vsync there.
I think vulkan in general in wine-3.4 does not have problems with vsync either, and i d3d9 or OpenGL wine does not have the same issues.
after quickly looking at that commit I don't think that is the reason vsync is "broken"
it is doing exactly what it was doing before, setting the fallback to 0 is just a hack to ignore the real problem.. which is .. well idk
@FireRat Yeah, i guess that was basically the same as Henri Verbeet said too.
I also tried to revert that line with the "old" one, but it did not solve it, so the issue is someplace else this time around. What is nice is that doing this hack makes it work "as intended" atleast from a user perspective :)
@FireRat it turns out that vsync is on system wide for me, at least according to glxgears.
I'm using dri3, not dri2, and the opensource amdgpu driver on my Radeon RX480 GPU. And I don't have the vblank_mode option. It's not recognized, and it doesn't do anything. So I'll keep searching the webz until I figure that one out. :)
What I'm not strictly certain about is whether or not this happened recently or if I've always had vsync on. WoW is the only game I've ever really been running any fps counters in, and if wine (up to the recent 3.3-3.4ish changes) could override the system wide setting, I wouldn't have been aware about the system wide setting even if it was there. Which it probably was.
But I'll give the vsync hack a chance and see if I can't bypass the system wide vsync with it! And I need to figure out how to turn off that system wide thing too, because it's kind of hard to do any real sort of benchmarking when the answer is always 60, hehe! ;)
Thanks for the help and pointers, though! 👍
@Goldpaw try vblank_mode=0 wine ....
maybe games should be able to turn vsync off, I just remember in the dim and dark past that I had to unset it
but for chasing down fps cap in games it makes sense to ensure cap is off system wide
For nVidia binary blob it's: __GL_SYNC_TO_VBLANK=0
Still need the hack tho, but interesting to test if different hardware has different behavior tho :)
Games should be > driver defaults tho, but it has happened that drivers do not pay attention to that if in some sort of "forced mode".
@FireRat setting the vblank_mode=0 environment variable actually did it. The framerate in Ironforge was back up in the 160-170 area when just standing around. No cap. Thank you! 👍
Of course, with this override I can't toggle the vsync in-game, so I'm still going to try the hack. What I want here is the "correct" behavior from a user's perspective, meaning the in-game option will decide whether or not vsync is used.
For me personally I'd just go with vsync off at all times, since the amdgpu "TearFree" option prevents any screen tearing regardless of whether vsync is on or off. But since I'm putting this in an AUR package for Arch Linux Users and I have no way of knowing whether they've set it up with that option or not, I'd like to have stuff as far as possible work as one would expect.
@SveSop yeah, I tried that __GL_SYNC_TO_VBLANK=0 setting too, but that appears to only affect nvidia. Doesn't change anything for my AMD card. The vblank_mode=0 mentioned by Firerat did it, though.
well, thus far the only thing I have found that differs in logic is
dlls/dxgi/factory.c
wined3d_desc.swap_interval = WINED3D_SWAP_INTERVAL_DEFAULT
that was WINED3DPRESENT_INTERVAL_DEFAULT
in the old code, case ...DEFAULT and ...ONE would swap_interval = 1; WINED3D_SWAP_INTERVAL_DEFAULT` is currently an unset enum ~0u, so it will trigger the fallback to 1 ( or 0 with hack )
but I haven't followed any paths yet, so I don't know if that is active, or when it is active
I'll try and follow it later, after sticking a tonne of FIXMEs in to spew out the various "flag" changes
@Goldpaw the hack will set vsync=off when it doesn't recognise the swap_interval
at the moment it seems to not recognise the swap_interval
I'm confused now , so system wide vsync=off, it should have capped it regardless..
not what I would have expected
Hmm.. from what i understand, the line: swap_interval = swapchain->desc.swap_interval > 4 ? 1 : swapchain->desc.swap_interval; should mean that if swap_interval is set to anything larger than 4, it should default to "1".. and that is "on" i guess.
Found some reference to swapinterval on the nvapi documentation, although i am not entirely sure how to interpret that:
enum | EValues_OGL_DEFAULT_SWAP_INTERVAL { OGL_DEFAULT_SWAP_INTERVAL_TEAR = 0, OGL_DEFAULT_SWAP_INTERVAL_VSYNC_ONE = 1, OGL_DEFAULT_SWAP_INTERVAL_VSYNC = 1, OGL_DEFAULT_SWAP_INTERVAL_VALUE_MASK = 0x0000FFFF, OGL_DEFAULT_SWAP_INTERVAL_FORCE_MASK = 0xF0000000, OGL_DEFAULT_SWAP_INTERVAL_FORCE_OFF = 0xF0000000, OGL_DEFAULT_SWAP_INTERVAL_FORCE_ON = 0x10000000, OGL_DEFAULT_SWAP_INTERVAL_APP_CONTROLLED = 0x00000000, OGL_DEFAULT_SWAP_INTERVAL_DISABLE = 0xffffffff, OGL_DEFAULT_SWAP_INTERVAL_NUM_VALUES = 9, OGL_DEFAULT_SWAP_INTERVAL_DEFAULT = OGL_DEFAULT_SWAP_INTERVAL_VSYNC_ONE }
-- | --
So.. could this mean that if vsync is disabled, the value is 0xffffffff? That is certainly > 4, so one could contemplate that it is related... The fact is that setting the line to >4 ? 0 changes things up..
The file ./include/wine/wined3d.h changes things between 3.3 and 3.4 when it comes to declaring "swap_interval"..
3.3:
UINT swap_interval;
3.4
enum wined3d_swap_interval swap_interval;
@SveSop @FireRat so I've done some more testing here.
First off, vblank_mode=0 is (for my AMD card) a guaranteed forced overrided of both system- and application settings. When I set that, vsync is always off, regardless of in-app vsync settings. This goes for both wine and native applications. Set that variable, and there is no vsync.
Second, I discovered the vsync problem is active everywhere for me, not just in wine. In-app vsync options in native linux games had no effect either. I was capped at 60 everywhere. So I tried adding vblank_mode=0 to the launch options of those games, and voila, much higher fps. And without it, my fps was capped at 60, regardless of whether or not vsync was set in the game options.
The vsync wine hack fixes the issue for wine. When using wine with this hack (but not the aforementioned env variable), the in-game vsync option allows me to actually toggle vsync. So at least for wine this fixes the issue, returns it to working as it's supposed to.
But this leads me to think we're barking up the wrong tree when we assume something wine did between 3.3 and 3.4 caused vsync to always be on. Because if wine was the cause, only apps run through wine would be affected, right? But as it turns out - at least on my system - all opengl apps have this problem. The system forces vsync on, regardless of in-game settings.
I haven't tried downgrading mesa or amdgpu yet, but will. Though since we're both nvidia and amd users experiencing this, I don't really expect it to be a driver issue.
puzzled
@Goldpaw Well, for my nVidia card, the toggle in the driver settings in linux aswell as the __GL_SYNC_TO_VBLANK variable changes things in both linux and wine. Setting this enabled (vsync=on) in linux, and launching wine with a game/program that supports vsync changing, still do the job... so this might be something different with amd drivers vs. nvidia.
That NvAPI thing could be interesting tho, but im not sure that wine utilizes this to anything more than providing the .dll for games that support using NvAPI?
EDIT:
And by "doing its job" it does as i always thought - The driver setting is for games/programs not providing their own setting for this... its not a "forced override", although i think that in windows you have a ON/OFF/Application setting, so you CAN actually force it. Been a while, so i dont remember exactly.
enum EValues_OGL_DEFAULT_SWAP_INTERVAL {
OGL_DEFAULT_SWAP_INTERVAL_TEAR = 0,
OGL_DEFAULT_SWAP_INTERVAL_VSYNC_ONE = 1,
OGL_DEFAULT_SWAP_INTERVAL_VSYNC = 1,
OGL_DEFAULT_SWAP_INTERVAL_VALUE_MASK = 0x0000FFFF,
OGL_DEFAULT_SWAP_INTERVAL_FORCE_MASK = 0xF0000000,
OGL_DEFAULT_SWAP_INTERVAL_FORCE_OFF = 0xF0000000,
OGL_DEFAULT_SWAP_INTERVAL_FORCE_ON = 0x10000000,
OGL_DEFAULT_SWAP_INTERVAL_APP_CONTROLLED = 0x00000000,
OGL_DEFAULT_SWAP_INTERVAL_DISABLE = 0xffffffff,
OGL_DEFAULT_SWAP_INTERVAL_NUM_VALUES = 9,
OGL_DEFAULT_SWAP_INTERVAL_DEFAULT = OGL_DEFAULT_SWAP_INTERVAL_VSYNC_ONE
};
So.. Does disabling VSYNC on nVidia make the value become 0xffffffff (and thus >4)?
Well.. i think it's clear something weird is up, as it seems the value is 0xffffffff no matter what.
Compiling with:
swap_interval = swapchain->desc.swap_interval > 0xfffffffe ? 0 : swapchain->desc.swap_interval;
made the behaviour functional.. ie. vsync could be turned on/off in the game.
Setting:
swap_interval = swapchain->desc.swap_interval > 0xfffffffe ? 1 : swapchain->desc.swap_interval;
would keep vsync enabled no matter what setting used ingame or otherwise forced.
I suspect something is up with the enum wined3d_swap_interval swap_interval; value.. The wined3d_swap_interval value is also something "new" in 3.4.
ok, so did a little testing and I can confirm that both my laptop and desktop are not afflicted by this vsync bug
I also have a diff so we can see some,very basic, info
diff --git a/dlls/wined3d/swapchain.c b/dlls/wined3d/swapchain.c
index 26ebba9ea7..c4ab150cf0 100644
--- a/dlls/wined3d/swapchain.c
+++ b/dlls/wined3d/swapchain.c
@@ -691,7 +691,9 @@ static void wined3d_swapchain_update_swap_interval_cs(void *object)
context = context_acquire(swapchain->device, swapchain->front_buffer, 0);
gl_info = context->gl_info;
+ FIXME("\n\tswapchain->desc.swap_interval before\t%d\n",swapchain->desc.swap_interval);
swap_interval = swapchain->desc.swap_interval > 4 ? 1 : swapchain->desc.swap_interval;
+ FIXME("\n\tswapchain->desc.swap_interval after\t%d\n",swapchain->desc.swap_interval);
if (gl_info->supported[WGL_EXT_SWAP_CONTROL])
{
I see a pair of 0s and a pair of 1s when I toggle vsync in game
I also see fps cap
so yeah,, for me it ain't broken
will be interesting to see what you all get
Edit, prefixed a newline in msg output
less blank magic , more blank science
mesa 18.1 git
branch 'master' of git://anongit.freedesktop.org/mesa/mesa
src/util/xmlpool/t_options.h
DRI_CONF_OPT_BEGIN_V(vblank_mode,enum,def,"0:3") \
DRI_CONF_DESC_BEGIN(en,gettext("Synchronization with vertical refresh (swap intervals)")) \
DRI_CONF_ENUM(0,gettext("Never synchronize with vertical refresh, ignore application's choice")) \
DRI_CONF_ENUM(1,gettext("Initial swap interval 0, obey application's choice")) \
DRI_CONF_ENUM(2,gettext("Initial swap interval 1, obey application's choice")) \
DRI_CONF_ENUM(3,gettext("Always synchronize with vertical refresh, application chooses the minimum swap interval")) \
DRI_CONF_DESC_END \
DRI_CONF_OPT_END
Edit : I think table is right
| vblank_mode | vsync default | can toggle |
|---|---|---|
| 0 | off | no |
| 1 | off | yes |
| 2 | on | yes |
| 3 | on | adaptive |
@FireRat awesome! Got all the vblank modes described right there. 👍
Since my last thest I actually tried setting vblank_mode=1, and in all native linux apps it did indeed obey the application's choice. I was able to turn it on and off in-game with it then, and it started without it. Just like mesa says.
Wine however did not obey. I tried the wine version without the hack, and with vblank set to anything but 0 - or not at all, it was simply always on. And with 0, it was always off. Application never got the choice. With the vsync hack it functioned as if I'd set the vblank mode to to 1, meaning the app (WoW in this case ofc) could choose.
Can this be a case of wine-dev and wine-staging simply not having caught up to the mesa changes yet? ( edit: Nah, the vblank modes have been around for years. Dug a little more on the webz. So it's not that. )
@Goldpaw , well my laptop which has
OpenGL renderer string: AMD RV635 (DRM 2.50.0 / 4.15.0-1-amd64, LLVM 6.0.0)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.1.0-devel (git-d07a49fb18)
and desktop
OpenGL renderer string: GeForce GT 620/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 390.42
and I have no issues with toggle,
I get these with my info diff
0030:fixme:d3d:wined3d_swapchain_update_swap_interval_cs swapchain->desc.swap_interval before 0
0030:fixme:d3d:wined3d_swapchain_update_swap_interval_cs swapchain->desc.swap_interval after 0
0030:fixme:d3d:create_buffer_heap found custom geo_heap_size of 200mb
unset __PBA_GEO_HEAP if you don't want this
0030:fixme:d3d:create_buffer_heap found custom cb_heap_size of 1mb
unset __PBA_CB_HEAP if you don't want this
0030:fixme:d3d_perf:wined3d_buffer_heap_create PBA: using GL_CLIENT_STORAGE_BIT quirkPBA: using GL_CLIENT_STORAGE_BIT quirkInitialized PBA (geo_heap_size: 209715200, cb_heap_size: 1048576, ub_align: 256)
0009:fixme:imm:ImmReleaseContext (0x50050, 0x18c598): stub
0046:fixme:d3d:wined3d_swapchain_update_swap_interval_cs swapchain->desc.swap_interval before 1
0046:fixme:d3d:wined3d_swapchain_update_swap_interval_cs swapchain->desc.swap_interval after 1
and yeah, I'm using hax to get pba working on my laptop
maybe it is my mesa 18.1-git
ok , been testing WoW retail ( no fps I didn't log in )
swapchain->desc.swap_interval before 0
swapchain->desc.swap_interval after 0
swapchain->desc.swap_interval before 0
swapchain->desc.swap_interval after 0
swapchain->desc.swap_interval before -1
swapchain->desc.swap_interval after -1
so what is that -1 ?
that would be adaptive vsync glXSwapIntervalEXT(-1)
setting vsync enabled in WoW gives 1
filter out all that log spam
WINEPREFIX=~/.wineWoW wine World\ of\ Warcraft/Wow-64.exe 2>&1|grep -o swapchain-.*
I can't test the adaptive on amd, since my laptop doesn't have EXT_swap_control_tear
Conclusion, wine ain't broke
would be interested in seeing the before and after numbers
Conclusion, wine ain't broke
would be interested in seeing the before and after numbers
Interesting that wine is not broken... since Mr. Kucia posted 2 patches (+ 1 test) for this... or was it with .git you did your tests?
https://source.winehq.org/git/wine.git/commitdiff/6aeb444e4ca7f8e60c503858bc52e4a75b150f7a
https://source.winehq.org/git/wine.git/commitdiff/81459fb8a2ddedcab68683991611e463c4fee516
And a test:
https://source.winehq.org/git/wine.git/commitdiff/3c53b193f7f36cb7ebd6cab42524de87f1ffb0df
At work now, but going to do some tests tonight.
And it seems as wine-staging is rebased and removing the -# Patchset wined3d-dxgi_swapchain_Present patch.
So wine-git + wine-staging-git should have working vsync :)
VSync working now :)
I updated my wine-staging-pba-patched repo with:
wine-git: afef57f872433bcd3032c2ccbc0453bef5b62178
wine-staging: 4d7af4085f1e62fb440b732882f53f732ebc131b
https://github.com/SveSop/wine-staging-pba-patched
Closing this "issue" now, cos the vsync disgussion is over, and i guess rebasing wine-pba was not that important.
Nope , I wasn't testing against those patches
I was on my wine-staging-pba-3.4-heap_size_envvars branch which is
- Tag: wine-3.4
- Tag: v3.4 ( staging )
- patchset commit on My PBA branch
thanks again for this @FireRat i have a ge-wine build that was pulling from svesop's repo due to being rebased, with yours i can remove the ffxiv patching afterwards. i went to make a build today and realized svesop's repo was no longer there