Re: Backing out DRI2 from server 1.5
On Sun, 2008-08-10 at 19:11 -0400, Kristian Høgsberg wrote: On Sun, Aug 10, 2008 at 5:07 PM, Dave Airlie [EMAIL PROTECTED] wrote: On Mon, Aug 11, 2008 at 5:46 AM, Kristian Høgsberg [EMAIL PROTECTED] wrote: My plan is to included a device specific 32 bit bitfield per buffer in the reply to DRI2Getbuffers, which is what the client calls to ask the server for buffer info. These bits can indicate properties such as tiling. In the DRI2Connect call, I'm sending back the DDX version, so the DRI driver will know which bits are valid. I actually meant to cc the lists on this, I dislike device specific limited allocation bitfields as an API in general, can we add something with a pointer or length + array? I debated whether to just use a bitfield or send along an arbitrary sized device private block. What's a little tricky about an opaque block is that we can't byteswap it in the protocol; we don't need that, of course, but it just feels a little icky. More to the point, I could not come up with anything that would require more than just a few bits, and always including this bit field makes a lot of common cases much easier - tiling, interlacing, swizzling... I dunno? What else might there be? We can add another request if there ever is a need for more data. For GEM I don't need tiling or swizzling information. I just ask the kernel what the answer is, since the DDX hadn't been telling me the information I needed in the past. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Backing out DRI2 from server 1.5
On Mon, Aug 11, 2008 at 5:46 AM, Kristian Høgsberg [EMAIL PROTECTED] wrote: On Sat, Aug 9, 2008 at 7:28 PM, Dave Airlie [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 2:23 AM, Kristian Høgsberg [EMAIL PROTECTED] wrote: On Tue, Aug 5, 2008 at 10:42 AM, Michel Dänzer [EMAIL PROTECTED] wrote: Hi Kristian, On Tue, 2008-08-05 at 21:01 +1000, Dave Airlie wrote: On Tue, Aug 5, 2008 at 5:39 PM, Alan Hourihane [EMAIL PROTECTED] wrote: On Mon, 2008-08-04 at 17:20 -0400, Kristian Høgsberg wrote: Since it looks like we'll be going with GEM for the memory manager, I'll have to revisit some of the DRI2 design decisions. As a first step, I want to back out the DRI2 stuff from the 1.5 X server entirely, since it uses TTM API for creating and mapping the DRI2 sarea. We're in feature freeze with 1.5 and I won't be able to update it in time anyway, so the best option is to just back it out instead of releasing a server with modules expecting an API that was never released. GEM is currently Intel specific. It seems as though the memory managers are going to be driver specific at this time, so we can't have the Xserver relying on a specific one. Maybe we should have some callbacks to the driver for DRI2 specific handling ? I think that is the current plan, the shared area for DRI2 will be an shm object independent of memory manager. everything else will be 32-bit handles. Has any of this been done yet anywhere? I need memory manager agnostic DRI2 for a project I'm working on, so I thought we should at least exchange ideas for the direction to take. I've just started to look into this again, and while the main change I want to do is to make it memory manager agnostic, there's a couple of other things I'd like to change at this point: 1) with DRI2. I kept the buffer swap in the client since I didn't want to incur a server request to do this. This decision meant that we had to keep much of the complexity for synchronizing clip rects between server and DRI clients in place. What I realized in the mean time is that we always send a few requests to post damage after each swap buffer, so introducing a DRI2 request to do swap buffers and post damage shouldn't affect performance but will make everything much simpler. This will also eliminate the need for the DRI lock, which for DRI2 was only used to synchronize access to cliprects. 2) Now that we don't need to communicate cliprects to the DRI clients, the somewhat complex DRI2 sarea and event buffer becomes a little harder to justify as we only use this to detect changes in attached buffers. George's swrast DRI driver uses a simpler approach there: he hooks the dd_function_table::Viewport function and asks the loader for the drawable size. I'd like to do something similar for DRI2, which will completely eliminate the need for the sarea. The DRI2 DRI driver will ask the loader (libGL, which will forward the query over protocol or AIGLX, which will ask the DRI2 module directly) for the dimensions and memory manager buffers backing the current drawable. This costs a roundtrip, but this was part of the old design too and inherent in GLX, in that multiple DRI clients need to agree on the memory manager buffers backing the aux renderbuffers. Thus you need to go to the X server one way or the other. 3) Let the DDX driver allocate the auxillary buffers. I went back and forth on this a bit and in some sense it's an arbitrary decision: both the DDX and the DRI drivers know enough about the hardware to allocate buffers with the right stride/tile/etc properties. Doing it in the DDX means that the DRI driver need to tell the DDX driver what buffers to allocate (using the DRI2CreateWindow), but on the other hand it avoids tricky allocation races with multiple DRI clients rendering to the same drawable. And without the sarea, doing it in the client would incur an extra round trip: you would first have to ask the server about the drawable size, then allocate and tell the server about the buffers you allocated. This lets the DDX driver implement special cases such as allocating a full screen back buffer that has the right properties to be used as a scan out buffer for page flip cases. Which in turn becomes a lot simpler when the buffer flip happens in the X server. And for redirected windows, the back buffer can be another pixmap so that buffer flips can be implemented as setting a different window pixmap. This all sounds like a lot of work, but it's mostly simplifications and I expect to make some good progress towards it this week. In the mean time I'll drop the dri2 bits from the xserver 1.5 and mesa 7.1 branches. How are we communicating information like tiling properties of buffers between DDX and DRI clients now? These are driver specific properties and usually the sarea was used. For example radeon can change the tiling property of the front buffer if the mode
Re: Backing out DRI2 from server 1.5
On Sun, Aug 10, 2008 at 5:07 PM, Dave Airlie [EMAIL PROTECTED] wrote: On Mon, Aug 11, 2008 at 5:46 AM, Kristian Høgsberg [EMAIL PROTECTED] wrote: My plan is to included a device specific 32 bit bitfield per buffer in the reply to DRI2Getbuffers, which is what the client calls to ask the server for buffer info. These bits can indicate properties such as tiling. In the DRI2Connect call, I'm sending back the DDX version, so the DRI driver will know which bits are valid. I actually meant to cc the lists on this, I dislike device specific limited allocation bitfields as an API in general, can we add something with a pointer or length + array? I debated whether to just use a bitfield or send along an arbitrary sized device private block. What's a little tricky about an opaque block is that we can't byteswap it in the protocol; we don't need that, of course, but it just feels a little icky. More to the point, I could not come up with anything that would require more than just a few bits, and always including this bit field makes a lot of common cases much easier - tiling, interlacing, swizzling... I dunno? What else might there be? We can add another request if there ever is a need for more data. Kristian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Backing out DRI2 from server 1.5
On Sun, 2008-08-10 at 19:11 -0400, Kristian Høgsberg wrote: On Sun, Aug 10, 2008 at 5:07 PM, Dave Airlie [EMAIL PROTECTED] wrote: On Mon, Aug 11, 2008 at 5:46 AM, Kristian Høgsberg [EMAIL PROTECTED] wrote: My plan is to included a device specific 32 bit bitfield per buffer in the reply to DRI2Getbuffers, which is what the client calls to ask the server for buffer info. These bits can indicate properties such as tiling. In the DRI2Connect call, I'm sending back the DDX version, so the DRI driver will know which bits are valid. I actually meant to cc the lists on this, I dislike device specific limited allocation bitfields as an API in general, can we add something with a pointer or length + array? There are so many possibilities here. I'd rather see something that didn't require a secret agreement between the server and client though. That seems prone to versioning failures. One answer would be to have a version number and then a random collection of bytes; that at least would let us change the encoding in a reasonably compatible fashion. Another alternative is a sequence of name/value pairs, where each value was a homogenous array of values. A third alternative is to have driver-specific requests to return this kind of data. That would let us completely document what was on the wire, although it would consume one request ID for each driver. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
