> On Maw, 2004-11-30 at 20:09, Thomas Hellström wrote: >> Textures in AGP memory is currently not allowed, but they are disabled >> in the Mesa driver as well, for some reason. If they are allowed in the >> future, Texture address checks probably have to be implemented but that >> should be a minor task. > > I certainly turned them off because they were crashing my box in the > original "hey it sort of works" codebase. I don't know if its that or if > someone did more work on it later. >
Nope, doesn't look like that from a quick glance. But there are obvious bugs in the texture memory allocation since the code fails to check properly that the allocation succeeded. >> The verifier is reasonably fast. It lowers the glxgears frame-rate a >> percent or two. However if it operates directly on AGP memory, it's a >> _real_ performance killer. So the userspace command buffer should be >> copied to kernel (static) system memory, checked and then copied again >> to the AGP ring-buffer. > > That should be fine if the command buffers are not too large (< 64K or > so) because they will be cached for the two passes. > Actually, I've been running with a 512Kb userspace / kernel buffer, and I've not seen any noticable drop in performance, but I'm not sure that the submissions actually will be that large with the programs I've tested. If the perfomance drop I experience with running the verifier on AGP memory is due to the fact that none of it is previously cached or that the processor cannot cache WC memory lines while reading? If it is due to the latter then we should be OK with large cacheable buffers. Otherwise we will run into trouble when the buffer does not fit in the cache. >> Comments are appreciated, particularly on the security assumptions and >> whether something doesn't fit well into the DRM coding style. > > Only real comment is that it would be better if the tables were > pre-initialized. gcc has some extensions for just specifying bits of an > array that might do this. Thats really it. > I planned to have the tables initialized as part of the module initialization, so it will never depend on an external master process initializing them, and there will be no chance of someone doing anything nasty before the verifier is initialized. I believe it's good for readability to have the command index right beside the intended action, and it will also be easier to extend / modify the code in this way. Thanks for the comments. /Thomas. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
