- Xonotic console timescale drivers#
- Xonotic console timescale android#
- Xonotic console timescale code#
- Xonotic console timescale plus#
Xonotic console timescale drivers#
Currently I have it looking for the msm trace events, but I think that it would be useful to have a small set of generic trace events which all the drm drivers can use, so that tools won't have to be looking for driver specific traces. and when pageflip is requested and when it completes (after rendering completes and after vsync)Īnd then I hacked up the perf timechart tool to display gpu information in the timechart, for a nice timeline overview.
So, first I added some trace points in the kernel drm/kms driver. using these instead is worth 2-3 fps in xonotic, and probably more in supertuxkart, but we'll come back to that.īut perf tool does not really help much with gpu or cpu/gpu interactions, at least not by itself.
Xonotic console timescale android#
On the downstream msm-3.4 based android kernel, we have iommu_map_range() and iommu_unmap_range(). Mapping/unmapping individual pages is not really the way to do it. In fact it showed me pretty quickly that the upstream IOMMU framework struggles with gpu type workloads. Now the linux perf tool is pretty nice just for identifying purely cpu bottlenecks. So before we get to the fun optimizations, we need to take care of any of the cpu side bottlenecks in the driver. It does no good to make the shader compiler generate 2x faster shaders (which I think is currently possible) if that is just going to take you from 30-50% utilization to 15-25% utilization at roughly the same fps. The key is to know which optimization to work on first. Now, a new graphics driver stack will always have lots of room for optimization (which is certainly true of freedreno). In the process, I noticed some games, such as supertuxkart, which had low fps, also also had unusually low gpu utilization (30-50%). I've put together a status table on the freedreno wiki. (Yes, an odd way to start a post about performance/profiling.) I added proper support for mipmaps/cubemaps/etc (multi-slice resources), killed a few gpu lockup bugs, installed a bunch of games and went looking for and fixing rendering issues. Now that msm drm/kms kernel driver is merged upstream, I've spent the last few weeks on a bit of a debugging / fixing spree. Gnome-shell running on freedreno + msm drm/kms: And so 3rd (and hopefully final-RFC round) of patches will go out soon. And added kms support in xf86-video-freedreno. Since then I've fixed a few things, added HW cursor support and more gpu debugfs bits to help when things go wrong. A couple weeks ago I send the 2nd round which added a3xx gpu support and basic kmscube working. So, earlier in the month, I sent first round of RFC patches, with just basic KMS support.
Xonotic console timescale plus#
It was a lot easier to get a general picture of how the hardware works that way! Plus I can generate register level headers from rnndb in the same way I do for the gallium driver.
Xonotic console timescale code#
In the end, I ended up instrumenting the code to trace all the register reads/writes, etc, wrote a small parser tool using envytools/librnn, and starting writing rnndb register database for the display controller registers. And I don't have any docs on the display controller. Even by android / vendor kernel standards, which are pretty low to begin with. Unfortunately, the msm android fbdev driver code is a real mess (at least the mdp4 parts). with the qcom android drivers, I can't really handle synchronization between processes, which gets really crazy w/ x11 and compositing window manager where you have sharing in both directions (as texture and/or render target), I can't handle page flipping (let alone page flipping synchronized with the GPU), and have general robustness issues. But that was always a short-term solution. For a while now, freedreno has been limping along with the msm fbdev and kgsl drivers from their android kernel tree, while I focused on the userspace gallium driver and ddx (xf86-video-freedreno). But in more convenient form factor for development.Īnd with this board that I've been developing a new msm drm/kms driver. It is basically the same SoC that is in the nexus4 (or the new nexus7).
About $150, quad-core krait, 2G DDR, SATA, gigabit ethernet. About a month ago, I received a new ARM dev board, a IFC6410! Which despite the boring sounding name is quite an impressive bit of kit.
0 kommentar(er)
