-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Airlie wrote:
I had a whole bunch of other stuff written, but I deleted it. I started ~ having Jon Smirl deja vu. Life is hard for us because King Solomon cut our drivers in half. He gave half to usermode and half to the kernel. ~ Wah! Waaaah! Wah! Okay. I'm done. |> managers or that we may want to have N memory managers now that will be |> gutted later. It seems that the real problem is that the memory |> managers have been exposed as a generic, directly usable, device |> independent piece of infrastructure. Maybe the right answer is to punt |> on the entire concept of a general memory manager. At best we'll have |> some shared, optional use infrastructure, and all of the interfaces that |> anything in userspace can ever see are driver dependent. That limits |> the exposure of the interfaces and lets us solve todays problems today. |> |> As is trivially apparent, we don't know what the "best" (for whatever |> definition of best we choose) answer is for a memory manager interface. |> ~ We're probably not going to know that answer in the near future. To |> not let our users have anything until we can give them the best thing is |> an incredible disservice to them, and it makes us look silly (at best). | | Well the thing is I can't believe we don't know enough to do this in some | way generically, but maybe the TTM vs GEM thing proves its not possible. It's not even TTM vs GEM that proves it. I passed around my first memory manager proposal, which was wisely NAKed, at DDC 2004. That we still have nothing four years later is the proof. TTM vs GEM underscores some issues that make it difficult. On one hand we want the kernel/user interface to directly map to the operations we want to do: allocate memory, free memory, access the memory from the CPU, and access the memory from the GPU. On the other hand, access arbitration between CPU/GPU, cache issues, TLB issues, and whole bunch of other ugly hardware reality makes the performance of that interface lose. If we flip from that interface to something that has decent performance we end up exposing an unreasonable amount of the mechanism in the API. Realistically, as soon as any mechanism is exposed in the API, maintenance loses. If we find a better way in 6 months or 5 years we're still stuck with the old way because the old way was been exposed. TTM and GEM each expose the two obvious mechanisms for handling this. One uses locks (basically) over a usermode critical region when command buffers are created. The other performs relocations in a critical region in the kernel. It's not clear to me which overall strategy is better. I've spent quite a bit of time looking at both interfaces. I've written a *basic* implementation of TTM-style fences. I've tried (and failed) to use TTM for command buffers and the framebuffer in the XGI XP10 driver. Some observations / comments about TTM: - - The barrier of entry is really high. The driver writer as to do a lot of work, it seems, to get anything working. - - I have often found myself wishing for more TTM documentation. - - The fencing mechanism is much too tightly coupled with the buffer mechanism. I've read the GEM documentation several times, and I think I have a good grasp of it. I don't have any non-trivial complaints about GEM, but I do have a couple comments / observations: - - I'm pretty sure that the read_domain = GPU, write_domain = CPU case needs to be handled. I know of at least one piece of hardware with a kooky command buffer that wants to be used that way. - - I suspect that in the (near) future we may want multiple read_domains. ~ I can envision cases where applications using, for example, vertex feedback mode would want to read from a buffer while the GPU is also reading from the buffer. - - I think drm_i915_gem_relocation_entry should have a "size" field. There are a lot of cases in the current GL API (and more to come) where the entire object will trivially not be used. Clamped LOD on textures is a trivial example, but others exist as well. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIMSi9X1gOwKyEAw8RAtB1AJwJUvUCwS1FcdL8LjP8ahVpru2/iwCfR9eA rfAmdoMsmZDHVmf7lRcN62Y= =yfRk -----END PGP SIGNATURE----- ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
