Re: VIA command verifier.
Hi. 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. I managed to get AGP textures working after some extra return-value checking. At least it seems rather stable, so I implemented a texture address check in the verifier, which checks that the texture is actually fetched from a client-drm-mapped memory region. System memory textures are still rejected. So unless someone has anything against this, I'll check it in in the via drm driver, and put up a modified unichrome_dri.so on the unichrome site for some serious beta-testing. Possibly also with different user command buffer sizes. /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
Re: VIA command verifier.
Thomas Hellström wrote: Hi. 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. I managed to get AGP textures working after some extra return-value checking. At least it seems rather stable, so I implemented a texture address check in the verifier, which checks that the texture is actually fetched from a client-drm-mapped memory region. System memory textures are still rejected. So unless someone has anything against this, I'll check it in in the via drm driver, and put up a modified unichrome_dri.so on the unichrome site for some serious beta-testing. Possibly also with different user command buffer sizes. /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 Great Thomas, Where is the source/patches for the DRM/3D driver? I will update my Fedora RPMS and try it out ... Cheers Terry -- Dr Terry Barnaby BEAM Ltd Phone: +44 1454 324512 Northavon Business Center, Dean Rd Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK Email: [EMAIL PROTECTED] Web: www.beam.ltd.uk BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software Dev Tandems are twice the fun ! --- 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
Re: VIA command verifier.
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
Re: VIA command verifier.
On Mer, 2004-12-01 at 12:19, Thomas Hellstrm wrote: 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. Might be worth finding the size needed - remembering a 512K buffer can be verified and copied in 32K chunks anyway. 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. AGP space is uncached. We could pull the pages out of AGP, write to them and put them back but we don't really support that right now. As a result all I/O to AGP pages is strictly synchronous. Pulling stuff from cachable memory and verifying it will prefetch lines from memory on the later processors (and you can also hint this with the prefetch(address) call in the kernel (prefetch about 320 bytes ahead is normally right). I'd expect the user pages are already in L2 cache anyway from when Mesa wrote the bits. --- 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
Re: VIA command verifier.
On Maw, 2004-11-30 at 20:09, Thomas Hellstrm 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. 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. Not all 3D functionality is in, but it is a start and it apparently works ok with the current Mesa unichrome driver. I've tested glxgears, chromium, tuxracer and the GL xscreensavers. I'd rather it under than overpermitted things too. 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. Looks good --- 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
