If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
No announcement yet.
Radeon VRAM Optimizations Coming, But Help Is Needed
@curaga I've just noticed multiple destroy entries for a number of buffers (tf2_1.bin). Is that expected behaviour?
Here an output snippet:
create buffer 17 at 18 ms (4096 bytes, high priority)
destroy buffer 17 at 19 ms
destroy buffer 17 at 19 ms
destroy buffer 14 at 19 ms
create buffer 18 at 25 ms (16384 bytes)
create buffer 19 at 30 ms (4096 bytes, high priority)
destroy buffer 17 at 32 ms
destroy buffer 19 at 32 ms
destroy buffer 14 at 32 ms
create buffer 20 at 40 ms (16384 bytes)
create buffer 21 at 45 ms (4096 bytes, high priority)
destroy buffer 17 at 46 ms
destroy buffer 21 at 46 ms
destroy buffer 20 at 46 ms
Sorry, I missed that this was one of the first traces.
I checked the text trace (from this thread, post #47). It was captured with pre-jan 17 code, which was slightly buggy in that it missed one creation path. When there's a destroy for a buffer that wasn't created, the binary converter tried to do a best guess.
So for the tf2_1 trace, there are no bugs in mesa code.
No need, they are quite usable despite the initial flaw. Only one or two buffers get created in the other path, and all other events are present for statistical purposes (so destroyed/sec is still accurate, for example).
No testing from me yet. Weeks later I am still horribly busy at university (and fighting with the SuperIO of my new typing machine). Besides, my Gentoos are having a (severe) hiccup, probably python/python-exec/portage related. Also there was libpng and libjpeg-turbo updates which cause recompiles of the whole system.
I didn't manage to get Mesa 10.0.x compiled on my main box (strangely on my new E-350 acquisition though, but then the PSU of that laptop failed ... I am a real magnet for luck, right?) and I got all my humble bundle games and steam on the main box where I would do testing.
It kinda sucks since normally I only see my home for 2-3 wake hours in the late evening (due to work, f*cking PhD stress) and besides emails and newsreading all I do is a little gaming - and it would have been nice to use that opportunity at the same time to help improving the free driver stack as a normal user. (Gaming to make the driver better sounds awesome, doesn't it? )
Is there any distribution that carries all the neccessary stuff for the tracing and testing and that could be used quickly for the tests? I have several free older IDE drives with enough space to quickly put something on. I could then just boot this and do the testing.