Re: Merging DRI interface changes
On Fri, 2007-10-12 at 10:36 +0100, Keith Whitwell wrote: Michel Dänzer wrote: On Fri, 2007-10-12 at 10:19 +0100, Keith Whitwell wrote: Michel Dänzer wrote: On Thu, 2007-10-11 at 18:44 -0400, Kristian Høgsberg wrote: On 10/11/07, Keith Whitwell [EMAIL PROTECTED] wrote: 3) Share buffers with a reference counting scheme. When a client notices the buffer needs a resize, do the resize and adjust refcounts - other clients continue with the older buffer. What happens when a client on the older buffer calls swapbuffers -- I'm sure we can figure out what the correct behaviour should be. 3) Sounds like the best solution and it's basically what I'm proposing. I agree, it looks like this can provide the benefits of shared drawable-private renderbuffers (support for cooperative rendering schemes, no waste of renderbuffer resources) without compromising the general benefits of private renderbuffers. Yes, I'm just interested to understand what happens when one of the clients on the old, orphaned buffer calls swapbuffers... All the buffers should be swapped, right? Large and small? How does that work? If the answer is that we just do the swap on the largest buffer, then you have to wonder what the point of keeping the smaller ones around is? To make 3D drivers nice and simple by not having to deal with fun stuff like cliprects? :) Understood. I'm thinking about a further simplification - rather than keep the old buffers around after the first client requests a resize, just free them. I see, but how would that work? If it hasn't happened yet, the plan seems to be to make BOs strictly reference counted. No matter who creates the new renderbuffers, some clients may keep the old ones referenced until they catch up. If it's still somehow possible to avoid wasting resources in this case, that would be nice, but otherwise it seems like too much of a corner case to worry about. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging DRI interface changes
On Fri, 2007-10-12 at 11:53 -0400, Kristian Høgsberg wrote: They do drop support, yes, but of course, I'm committing a series of X server patches along with this to let AIGLX load the new driver API. This means that you can't load a git dri driver with any released X server, which is the inconvenience you're referring to I guess. We can get an X server release done reasonably quickly to avoid major inconvenience for developers at least. I do think it's worth moving forward with this though. Personally, I get these patches off of my plate and can focus on the next steps. I'm all for making forward progress and abandoning broken interfaces as early as possible. The only people this will inconvenience should be developers and early adopters, and we can help them by pushing releases of the related bits sooner rather than later. I'm assuming that the X server patches you mention will still build and run against older other bits, right? -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8056] s3tc broken in ut2004
http://bugs.freedesktop.org/show_bug.cgi?id=8056 --- Comment #39 from [EMAIL PROTECTED] 2007-10-13 16:27 PST --- I have done some more testing: - I can't find any texturing issue with s3tc enabled now. - I have found no regressions caused bu this patch with non-s2tc games/apps. So it would appear that all that is needed is the cleanup and version checking and we are good to go. At least I am a happy camper ( Call of Duty much nicer now =) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
