07:01 XenoPL: all the rpms (x86_64 and i686) are build, lets see how it goes
08:16 mannerov: so ?
10:44 XenoPL: still crash, I need to verify if patch was correctly applied, my plan was to patch te source by hand then rebuild package
10:46 XenoPL: but somehow patch doesn't like it, :q
10:47 XenoPL: (sorrry vim on the wrong keyboard :)) there's a message that patch unexpectedly ends in the middl of line
10:52 XenoPL: so I had to left that for a moment do some rl job, now i've sorted it out, so i'll rebuild mesa and try once again
11:05 mannerov: ok no worry
11:09 orbea: XenoPL: try using wget with this link, patches can be picky if you don't copy it just right... https://paste.centos.org/view/raw/348821c3
11:19 XenoPL: ok got that sorted out, aunt duck told me to add new line at the end ;)
13:33 XenoPL: Unfortunatelly replaying trace still crashes, new log: http://x-s.com.pl/pliki/BMS_apitrace_20200508_15:30.log
14:05 mannerov: hum weird
14:05 mannerov: it goes further
14:05 mannerov: but the patch should have helped
14:05 mannerov: at the place of the crash
14:51 mannerov: XenoPL: could you upload the trace somewhere (after compression)
14:57 XenoPL: it's uploaded here: http://x-s.com.pl/pliki/F4BMS_nonine.trace.xz
14:57 XenoPL: mannerov: ^
14:57 mannerov: thanks
14:58 XenoPL: u're welcome :)
15:15 mannerov: btw did you try the game with the patch ?
16:30 mannerov: ok, I reduced my available memory and I can reproduce the bug with the trace (else the trace plays fine)
17:11 mannerov: XenoPL: may I ask you to test something again ?
17:11 mannerov: I still have a failure with the trace but I think it is an apitrace bug
17:12 mannerov: thus I'd like to see if with my new patch the game works
17:14 mannerov: https://paste.centos.org/view/986801dc
17:37 XenoPL: ok I'll try this new patch
17:39 XenoPL: This patch should be applied with previous one or it's gonna replace it?
17:39 XenoPL: mannerov^
17:39 mannerov: it replaces it
17:40 XenoPL: oki
17:52 XenoPL: Althoug Im not sure i'll be able to test it today, for the weekend I move to my fiance flat, away from my toy rig. But maybe I'll be able to do it tommorow as I'll be there to do weekly housekeeping.
17:54 dhewg: test driving irc patches definitely counts as housekeeping!
17:58 mannerov: no worries
18:36 mannerov: siro__: Hi, I have some questions about advertised video memory
18:36 mannerov: I remember that the behaviour is different on xp and vista+
18:36 mannerov: do you mind reminding me ?
18:38 siro__: it's been a while since I investigated that
18:40 mannerov: yes I know
18:41 siro__: I think back in XP days the advertised video memory was a reserved area where the OS could keep sysmem and managed buffers
18:41 mannerov: According to what I find on internet, GetAvailableTextureMem returns video memory, which in d3d9 world is local video memory and AGP
18:42 mannerov: ok, keep on your explanation
18:47 siro__: AGP memory seems to be nothing special, from today's point of view
18:47 mannerov: AGP is GTT I think
18:48 mannerov: I couldn't find however how much there is on windows
18:48 mannerov: Our current implement doesn't seem to do the correct thing, which is to return vram and gtt memory real available memory
18:49 mannerov: but I remember that on vista+ the behaviour they implemented was quite different
18:49 mannerov: do you remember what you found ?
18:50 XenoPL: ok gtg have a good evening/weekend for everyone :) thanks again
18:51 mannerov: XenoPL: bye thanks
18:51 mannerov: siro__: also we seem to clamp vram memory to 4G. Why not allow more (at least on 64b, but why not even on 32b). We'd just clamp GetAvailableTextureMem
18:53 mannerov: The problem with XenoPL's bug I think is that most apps do not use GetAvailableTextureMem for good reasons to estimate anything
18:53 mannerov: Apparently other apis, like d3d7 is used to query the real video memory to target the allocations
18:53 mannerov: else some apps to allocate until running out
18:54 mannerov: I think in the case of XenoPL, the game detects his 1GB with another API, and then allocates without checking any failures
18:54 mannerov: While nine only advertises (and use) 80% of the video memory
18:54 mannerov: thus the failures
18:55 mannerov: So we need to change the current system somehow. Which is why I need to get as much information to change it correctly.
18:57 mannerov: it's possible that just including gtt memory in out count would be enough
18:57 mannerov: but maybe it's not the best thing to do
18:59 siro__: we can't advertise more than 2G as some games use integer to store the vram amount
19:00 mannerov: you mean 4G ?
19:00 siro__: the 80% is due to the fact that on windows it's never possible to allocate 100%
19:00 mannerov: tell me more about it
19:00 mannerov: why 80%
19:01 mannerov: Give as much details than you remember, it will be useful
19:04 siro__: that's all I remember for now
19:04 siro__: that seems to be interesting: https://git.froggi.es/joshua/d9vk/commit/05f148bbd413ff663bbd682eebb20bf5a1ea439f?view=parallel&w=1
19:04 mannerov: where could I find more info ?
19:05 mannerov: well the spec says round, not clamp
19:05 mannerov: and yes, we don't currently
19:05 mannerov: siro__: did you have test programs ?
19:05 mannerov: I still have an horribly old windows xp laptop
19:06 mannerov: it won't be able to run many things before dying, but I can test things
19:06 mannerov: and I think iive has a windows 7 or 10
19:07 siro__: no, I don't even have a desktop computer any more
19:11 iive: win7
19:11 mannerov: siro__: how did you test last times the behaviour
19:15 siro__: I think I've crosscompiled d3d9_test.exe and run tests on windows
19:15 iive: i remember some people with 6GB video ram having issues with nine reporting of memory.
19:15 iive: there was an issue on github.
19:34 siro__: something else: I remember that some games expect the texture memory to change immediately
19:34 siro__: after allocating or free a texture
19:38 mannerov: good to know
19:38 mannerov: 20% of the memory seems a lot though
19:39 mannerov: I think 5% would be more reasonnable
19:39 mannerov: that means on 32bits we limit currently at 3.2GB texture memory
19:39 mannerov: it seems low
19:39 mannerov: (well on 64bits too)
19:43 mannerov: we also need to evict managed memory if an allocation fails
19:43 mannerov: spec says so
19:43 mannerov: while apps do not seem to mix managed memory and non-managed much
19:43 mannerov: we could still have an issue when there is a lot managed memory used
19:44 mannerov: (well technically it's supposed to be clever eviction, but we can probably just wipe everything)
19:45 siro__: yes, that should be ok
20:19 mannerov: siro__: wine does seem to clamp the result to UINT_MAX
20:19 mannerov: but allow more than 4G, even on 32bits
20:24 mannerov: iive: how much vram has your card ?
20:28 mannerov: oops, looks like when we are out of memory it can only get worse. We don't advertise as released the memory we tried to allocate
20:29 mannerov: I think
20:29 mannerov: hum no it should be fine
20:35 iive: mannerov, 1MB
20:48 mannerov: ouch
20:48 mannerov: siro__: does that sound right to you that our current code doesn't account memory allocated for MANAGED textures when we create their video resource