straight port of the Render accel in voodoo(4) to tdfx(4). passes rendercheck at both 16 and 24 bpp. should be free of endianness issues but only tested on x86. this is probably broken when used with DRI, we touch some 3d registers but never take a hardware lock or dirty the 3d state. quake3 still works, but we might render incorrectly when doing both Render and GL simultaneously. thanks to Alan Cox for the voodoo driver.
Created attachment 800 [details] [review] tdfx-render-accel-1.patch
Created attachment 812 [details] [review] tdfx-render-accel-2.patch first attempt was a no-op, i was using the old setup hooks. the voodoo driver needs to be converted to the new hooks too. this one actually has an effect. passes rendercheck in 16bpp but not 24bpp, and unscaled over blends get a 17x speedup according to renderbench. xcompmgr -a is entirely usable; -c is broken, but i suspect that's an unrelated bug in the driver since i'm not seeing the same problem on other hardware.
A few notes: - Need to multiply source by alpha in your PictOpSrc case, since you haven't premultiplied. - Syncing needs to be done before writing anything with cpu to framebuffer, so you appear to be correct. - The DRI lock is taken by the server on wakeup and dropped on block, so your driver doesn't need to worry about it. Since you don't appear to rely on any new set-once state, you don't need to worry about that either. However, I don't remember if tdfx had a set of flags in the shared area for sets of context dirtied. If so, just dumping 0xffffffff to it is probably the best idea. - I'm concerned about the x8r8g8b8 format support, but I haven't read the code thoroughly. Remember that you have to treat the x bits as 1. That means that the XXX should be srcFormat comment appears correct. But what about x8r8g8b8 src to a8r8g8b8 dest -- do the bits get filled with 1s?
Created attachment 971 [details] [review] tdfx-render-4.patch this version eliminates the magic numbers and accelerates just about all the simple blend ops. problem is, none of them work, except for Dst (because i short circuit it) and Src and In (which with da=1 are equivalent to normal framebuffer writes). not really sure what the deal is there.
I own an antiquated Voodoo3 2000 PCI and still use it as my primary video card (My next one will sit on a PCI Express slot and will be in my next computer). I also built my own copy of Xorg-X11 with 19 patches selected from Gentoo, Mandrake and RedHat Linux (these distinutions contains a lot more), running smoothly for one month and an half. What is the status of the patch? I would like to test but I read there is a conflict between DRI and Render. Also, are there other issues?
the patch is still somewhat in limbo due to the correctness issues i already described. it gives a nice speedup but doesn't render much of anything correctly. i'll come back to it sometime before 6.9 probably. rest assured it'll be merged once it's correct. if someone wanted to take a shot at finishing it, the voodoo3 datasheets are publicly available and should be sufficient.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Adding myself to the CC. I have a Voodoo3 now, and should be able to finish off this ancient monstrosity if nobody's already done so.
Corbin, do you still plan to do this?
Let's not pretend this is actually getting worked on.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.