Originally posted by Qaridarium
Announcement
Collapse
No announcement yet.
A Big Comparison Of The AMD Catalyst, Mesa & Gallium3D Drive
Collapse
X
-
Test signature
-
Originally posted by Drago View PostBridgman, I am sure if you do not know where the bottlenecks are, you(and other developers) have suspects. Is it in kernelmode or usermode part of the stack?
Performance optimization is basically :
- run some benchmarks & save the results
repeat forever {
- do some profiling
- form a theory re: where the bottleneck is
- change some code to test the theory
- re-run the benchmarks to see if things go faster
- (4 times out of 5) curse and discard the theory (or save as the basis for a more complex theory)
- (1 time out of 5) make happy noises and get some sleep
}Test signature
Comment
-
Originally posted by Qaridariumo bad thats not so funny..
Comment
-
Does the Radeons offer debug instrumentarium, like the CPUs. Cache misses, instruction counting, pipeline stalls. Or bassicaly is there way to know that your shader compiler is bad, and thus resulting stalls on more SIMDs than needed. In general how you evaluate FOSS r600 shader compiler? Dismissing shader compiler as the main bottlenck, open spaces for more agressive CPU micro optimizations, e.g: branch prediction hints, preventing CPU cache trashing etc. Well that will break portability to other platforms, but I am sure fglrx is full of that.
Comment
-
Originally posted by Qaridariumo bad thats not so funny..
Part of the problem is that profiling only tells you what the CPU is doing, not what the GPU is doing.
Drago, there are some hardware bits that can help but they're mostly aimed at getting the most out of the GPU once core driver isses are worked out, don't think they will help much here but we are going to look at those as well. Right now the open source driver hacked to not run anything on the GPU is still slower than fglrx doing full rendering (even on a single CPU core, apparently).
The "good" news (such as it is) is that this means there is a bunch of useful work that can be done before getting into the nasties of performance tuning on a pile of asynchronous engines (CPU execution, CPU cache flusher thingy, command processor, graphics pipe, shader core, vertex fetcher, texture fetchers/filters, GPU memory controller, GPU cache flusher thingy etc...).Test signature
Comment
-
Originally posted by pingufunkybeat View PostIf most of this work is in core Mesa (as I understood it, perhaps incorrectly), then all drivers will profit from this work?
Comment
-
There are some sw and hw bits that can provide detail in to the state of the GPU pipeline, but unfortunately, you generally need a fairly complex instrumentation infrastructure in place to get meaningful data out of them. Unfortunately, we don't really this in place yet in the open source driver.
Comment
-
Originally posted by Drago View PostThe focus is primarily on Gallium3D, so no intel there. An they are the second biggest contributor to Mesa. VMware being the first.
Comment
Comment