05:56 dhewg: mannerov: does "st/nine: Handle full pSourceRect better" fix that bug you mentioned recently?
06:53 mannerov: dhewg:
06:53 mannerov: no
06:53 mannerov: it's a fullscreen pb, and p*Rect are NULL for fullscreen
07:06 mannerov: and I still see no other solution than a checkbox
07:59 dhewg: hm ok
08:00 dhewg: i dont have time to dive in and look at the issue now though
08:00 dhewg: there's no way for us to detect the difference?
08:19 mannerov: there si
08:20 mannerov: but it's complicated
08:20 mannerov: I think
08:21 mannerov: The fs hack works by - if we are fullscreen - report the size of the X drawable
08:21 mannerov: but apparently it's possible for the X drawable to be bigger than the display resolution
08:21 mannerov: so instead it could detect the screen resolution I guess
08:22 mannerov: it will require testing under different scenario to check if it works (simulated desktop, fs hack or no, etc)
08:42 dhewg: k, i can look at it maybe next week, but if you have something you want me to test shoot away
08:43 mannerov: I haven't looked at it will rather look at some cool stuff to reduce virtual memory usage by a lot
08:43 dhewg: that sounds nice too! :)
08:44 mannerov: basically there is a way we can allocate more than 4GB on Linux on 32bits.
08:44 mannerov: Quite sure the creators of that Linux functionnality didn't think of this use case
08:44 dhewg: and the fshack issue doesn't sound that urgent, its the first report of it since we support it
11:20 XenoPL: Hi all, I've talked to Falcon4 BMS gfx guy and he more or less said that BMS does no checks if there's video memory left, just creates new texture. Expected behaviour is to place new textures in video ram, then if it's full in system ram allocated to video (is it GTT) then if this memory is out oom crash.
11:23 XenoPL: Does not ask me if such handling of memory is right or not. If it was me i'd check if there's a free mem (unless there's lots of such calls, then maybe separate thread that would periodically check for low mem condition and hint main gfx thread) But it is how it is
11:24 XenoPL: Expected amount of required video memory for now should be around 1GB
11:27 XenoPL: He also said for the apps he saw most of then never bothered themselves to query for available memory before alocations. Just create new teture/buffer hoping for the best
11:27 XenoPL: *texture
11:28 mannerov: thanks
13:33 XenoPL: rereading what I wrote I think some clarification needs to me made. Accordint to the guy, for the app vidmemory thing is transparent.
13:33 XenoPL: He said if he has 3GM onboard vidram and 16GB od system RAM, app sees 11GB of vid ram.
13:34 XenoPL: App just acclocates new textures. It's uderlying gfx stack places it in cards memory first, then system ram.
13:37 mannerov: I know that, but I have no clue how the GTT available size is estimated
13:38 mannerov: we need something that mimicks the windows size not the linux situation
13:38 mannerov: with d3d7 calls it's possible to get the info