Unfortunately, there's some not so great news.
Those performance comparisons are against the current i915 driver which has no memory management, so of course if one adds some memory management to it you should be getting an improvement.
This begs the question of what would happen if the i915 driver using GEM was benchmarked against a different memory management system, such as the open, stable and available TTM. TTM was passed up, despite being available, open and complete because the i915 team at Intel decided they didn't like it and they came up with their own solution and called it GEM.
TTM is complicated internally: it has support for a lot of rather "interesting" memory models that exist out there in the real world. This means GEM, while lacking that complexity, is useful for only a subset of hardware approaches out there. It does covers the lion's share of today's open source drivers, but I doubt that will hold true forever. This is problematic for obvious reasons, since hardware support is .. well .. pretty important.
And how do the two approaches stack up performance wise? Here are some numbers I've seen comparing i915 drivers built with GEM and TTM on the same hardware running the same benchmarks:
Test GEM TTM
openarena 52.8 fps 61.0 fps
ipers ~125000 Polygons/sec ~298000 Polygons/sec
texdown, subimage 148MB/s 1014MB/s
So while GEM offers improvements to the current i915 driver by adding memory management where none before existed, it really falls short of what is possible. In some cases, such as the texture uploading cases, massively short to the point of making some of the things we're considering doing not very tenable with this driver.
If other drivers are built on top of GEM instead of TTM (or something similarly well written) this pattern will repeat: drivers will improve somewhat, but still lag significantly behind what they should be doing. Worse, there may well be hardware that appears that simply won't work with GEM without it growing significantly in internal complexity (leading one to wonder if the end result won't be simply a hard road to rewriting TTM).
This is all complicated by the fact that TTM from DRM's dev branch hasn't made it into the Linux kernel yet despite being completed around a year ago, making it hard for people to rely on it (since it is up to individual distros to include this on their own). These bits of code have been sent for review but not integration into the Linux kernel. It's all a bit of an odd and unfortunate situation.
Hopefully whatever ends up in the kernel is flexible enough to allow something like TTM to occur so we can really go crazy with the graphics development on top of X.
Please x.org people, don't let your users down: Do The Right Thing(tm) and use the best available open technology.
8 comments:
It does seem rather odd to recreate a piece of code for no benefit and under initial benchmarks appears to be less performant. They may well be generous enough to help you out on that one if they have the spirit of the NVidia guys.
I believe Intel's argument would be a lot like yours regarding kicker - that even though the initial replacement implementation causes regressions and is inferior in many ways to the old one, it is much simpler to work with and will be far more maintainable in the long run.
Is this really true, or are the just prioritizing their own current needs at the expense of the larger community in the long run? I have no idea. It does seem like there's been an awful lot of resistance to using TTM from developers on all sides, though, given how big a performance boost it provides.
Sorry, for those that haven't heard of TTM before, could you provide a link or so to explain what it is and what it does? Perhaps it's obvious, but the thread on dri-devel is soo long that it probably has to be.
vladimir, take a look here: http://www.tungstengraphics.com/wiki/index.php/TTM_Memory_Manager
@henriknj
Thank you for the link :)
@dave: i hope so =)
@anonymous: "even though the initial replacement implementation causes regressions and is inferior in many ways to the old one, it is much simpler to work with and will be far more maintainable in the long run."
there are some important differences, however. plasma is more like TTM in that it is more complete and internally complex, building towards what we need.
GEM is like replacing plasma with a rewrite of kicker because you "don't get it".
in fact, that's exactly what it is.
"are the just prioritizing their own current needs at the expense of the larger community in the long run?"
i'm not sure they are prioritizing their own needs so much as simply failing to grasp the usefulness of TTM (partially at least through not understanding it) added with a healthy dolloping of NIH syndrome. really unfortunate.
"It does seem like there's been an awful lot of resistance to using TTM from developers on all sides"
well, not all sides, actually. XGI has used it, IBM has created and shipped hardware that has drivers using it, Tungsten uses it (obviously =) and i believe Gallium 3D will end up using it ... it's just from a relatively few, but very visible, developers.
@vladimir: "those that haven't heard of TTM before, could you provide a link or so to explain what it is and what it does?"
TTM is an advanced memory manager for GPUs. these days graphics chip sets have large amounts of memory that are used for various things like the screen buffers, textures, pixmaps, etc.. multiple processes need access to this memory as well.
with a memory manager, the driver can assign and protect memory for graphics usage much like the operating system kernel manages main memory for processes.
basically, it allows drivers to join the modern age ;)
GEM is also a memory manager, but quite a bit simpler in design and not nearly as performant as a result of this design. worse, this design will not work with various graphics architectures that exist, and some that are about to come down the pipeline.
I'm pretty disappointed by this whole blog post. The only thing you said is that GEM is not as good as TTM. Which is not surprising considering one is a week old and the other is I don't know how old.
And then your post sounds like TTM is a saint which descended from heaven to give Linux users fast graphics. If that were the case, we'd all be using it right now. The reason we are not is likely that it's just not as perfect as you describe it.
The good thing about GEM is that it gets stuff moving again. The rest is details.
@Benjamin: "The only thing you said is that GEM is not as good as TTM."
well, yes, that was the point of the posting. i did note that it was an improvement over what was there previously, of course.
"Which is not surprising considering one is a week old and the other is I don't know how old."
this isn't just about code maturity (there are places GEM can, and likely will, improve) but also about architecture. there are fundamental issues with how GEM is implemented that will prevent it from being applied to some of the hardware that is coming down the pipe; a limitation TTM doesn't have.
"your post sounds like TTM is a saint which descended from heaven to give Linux users fast graphics."
you may have read it that way, but then perhaps you missed the part about it being internally complex?
"If that were the case, we'd all be using it right now. The reason we are not is likely that it's just not as perfect as you describe it."
i never described it as perfect. in fact, i plainly noted it was internally very complex. however, the main reason it isn't used is due to it not being in the kernel yet which in turn is due to the people who maintain those bits not having a decent grasp on how TTM works.
this goes back to the complexity issue; however, that complexity is pretty much needed due to the completeness of it.
"The good thing about GEM is that it gets stuff moving again.
moving again? it was already moving; nothing was stalled here. in any case, GEM does provide an improvement over what was there but it is pretty dismal in what it actually delivers compared to what is possible with TTM today. in fact, it makes a number of things still implausible to implement.
"The rest is details."
in the world i come from, the above issues of acceptable performance ad hardware support aren't details.
Post a Comment