Re: Merging DRI changes
On Wed, 2007-06-13 at 18:48 -0400, Kristian Høgsberg wrote: Hi, I've finished the changes to the DRI interface that I've been talking about for a while (see #5714). Ian had a look at the DRI driver side of things, and ACK'ed those changes. I've done the X server changes now plus a couple of GLX module cleanups, and I think it's all ready to push: http://gitweb.freedesktop.org/?p=users/krh/mesa.git;a=shortlog;h=dri2 and http://gitweb.freedesktop.org/?p=users/krh/xserver.git;a=shortlog;h=dri2 One thing that's still missing is Alan H's changes to how DRI/DDX maps the front buffer. While the changes above break the DRI interface, they only require an X server and a Mesa update. Alans patches change the device private shared between the DDX and DRI driver and thus requires updating every DRI capable DDX driver in a non-compatible way. I've been trying to understand the change better in order to try to come up with a backwards compatible way to do the same. I think I've found a way to let the DDX driver tell libdri not to map the framebuffer and then do it itself. The problem is that Alans patch also changes the DRI driver side of things to not map the front buffer in the loader but in the driver code, based on extra info from the DDX device private. A compromise that will leave the DDX device private untouched is still require the framebuffer info (handle and size etc) through DRIGetDeviceInfo, but to not map the front buffer in the loader. Instead we just pass the handle and size into the DRI driver (as we do now), and the driver can then do the drmMap(). However, at this point I'm wondering what the intention of the patch is and if my suggested change somehow conflicts with that... help? Kristian, What you are suggesting sounds fine, but do you have patches to back up the suggested compromise so I can double check ?? Thanks, Alan. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging DRI changes
On Sat, 2007-06-16 at 15:05 +0200, Jerome Glisse wrote: On 6/16/07, Kristian Høgsberg [EMAIL PROTECTED] wrote: On 6/14/07, Keith Whitwell [EMAIL PROTECTED] wrote: Kristian Høgsberg wrote: Hi, I've finished the changes to the DRI interface that I've been talking about for a while (see #5714). Ian had a look at the DRI driver side of things, and ACK'ed those changes. I've done the X server changes now plus a couple of GLX module cleanups, and I think it's all ready to push: http://gitweb.freedesktop.org/?p=users/krh/mesa.git;a=shortlog;h=dri2 and http://gitweb.freedesktop.org/?p=users/krh/xserver.git;a=shortlog;h=dri2 One thing that's still missing is Alan H's changes to how DRI/DDX maps the front buffer. While the changes above break the DRI interface, they only require an X server and a Mesa update. Alans patches change the device private shared between the DDX and DRI driver and thus requires updating every DRI capable DDX driver in a non-compatible way. Kristian, Just letting you know Alan's on holidays this week, back on Monday. Ah, thanks. I was talking to Dave about it in IRC and it sounds like we can let the DDX driver add the front buffer map and let the DRI driver set it up without breaking the shared private struct. I've attached three patches (on top of my dri2 work) to illustrate the idea. What's missing is the i810 specific setup in mesa and a mechanism to indicate whether or not dri_util.c should map the buffer or if the DRI driver will do that. But that's all behind the DRI interface, so it's not a big deal. I'm not sure why we're doing this though. It looks like things are mostly working as it is, it's just not very elegant. And if we're about to shake things up with DRM memory manager enabled DDX and DRI drivers, do we want to add a hack like this? Kristian My feeling is that i would love to avoid hack and take advantage of undergoing change to fix API in sane way btw all component involved. Maybe we should accept to break backward compat at a point in order to properly and cleanly change all this. But as i can't devote time to this is just my personnal view. Actually, I agree here too. Alan. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging DRI changes
On 6/16/07, Kristian Høgsberg [EMAIL PROTECTED] wrote: On 6/14/07, Keith Whitwell [EMAIL PROTECTED] wrote: Kristian Høgsberg wrote: Hi, I've finished the changes to the DRI interface that I've been talking about for a while (see #5714). Ian had a look at the DRI driver side of things, and ACK'ed those changes. I've done the X server changes now plus a couple of GLX module cleanups, and I think it's all ready to push: http://gitweb.freedesktop.org/?p=users/krh/mesa.git;a=shortlog;h=dri2 and http://gitweb.freedesktop.org/?p=users/krh/xserver.git;a=shortlog;h=dri2 One thing that's still missing is Alan H's changes to how DRI/DDX maps the front buffer. While the changes above break the DRI interface, they only require an X server and a Mesa update. Alans patches change the device private shared between the DDX and DRI driver and thus requires updating every DRI capable DDX driver in a non-compatible way. Kristian, Just letting you know Alan's on holidays this week, back on Monday. Ah, thanks. I was talking to Dave about it in IRC and it sounds like we can let the DDX driver add the front buffer map and let the DRI driver set it up without breaking the shared private struct. I've attached three patches (on top of my dri2 work) to illustrate the idea. What's missing is the i810 specific setup in mesa and a mechanism to indicate whether or not dri_util.c should map the buffer or if the DRI driver will do that. But that's all behind the DRI interface, so it's not a big deal. I'm not sure why we're doing this though. It looks like things are mostly working as it is, it's just not very elegant. And if we're about to shake things up with DRM memory manager enabled DDX and DRI drivers, do we want to add a hack like this? Kristian My feeling is that i would love to avoid hack and take advantage of undergoing change to fix API in sane way btw all component involved. Maybe we should accept to break backward compat at a point in order to properly and cleanly change all this. But as i can't devote time to this is just my personnal view. best, Jerome Glisse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging DRI changes
On 6/14/07, Keith Whitwell [EMAIL PROTECTED] wrote:
Kristian Høgsberg wrote:
Hi,
I've finished the changes to the DRI interface that I've been talking
about for a while (see #5714). Ian had a look at the DRI driver side
of things, and ACK'ed those changes. I've done the X server changes
now plus a couple of GLX module cleanups, and I think it's all ready
to push:
http://gitweb.freedesktop.org/?p=users/krh/mesa.git;a=shortlog;h=dri2 and
http://gitweb.freedesktop.org/?p=users/krh/xserver.git;a=shortlog;h=dri2
One thing that's still missing is Alan H's changes to how DRI/DDX maps
the front buffer. While the changes above break the DRI interface,
they only require an X server and a Mesa update. Alans patches change
the device private shared between the DDX and DRI driver and thus
requires updating every DRI capable DDX driver in a non-compatible
way.
Kristian,
Just letting you know Alan's on holidays this week, back on Monday.
Ah, thanks. I was talking to Dave about it in IRC and it sounds like
we can let the DDX driver add the front buffer map and let the DRI
driver set it up without breaking the shared private struct. I've
attached three patches (on top of my dri2 work) to illustrate the
idea. What's missing is the i810 specific setup in mesa and a
mechanism to indicate whether or not dri_util.c should map the buffer
or if the DRI driver will do that. But that's all behind the DRI
interface, so it's not a big deal.
I'm not sure why we're doing this though. It looks like things are
mostly working as it is, it's just not very elegant. And if we're
about to shake things up with DRM memory manager enabled DDX and DRI
drivers, do we want to add a hack like this?
Kristian
commit 42ed8fb718bd552a8b6a03efa0e739cc9ccf9818
Author: Kristian Høgsberg [EMAIL PROTECTED]
Date: Fri Jun 15 18:52:54 2007 -0400
Tell libdri not to map the front buffer if it's at least 5.4.0.
diff --git a/src/i810_dri.c b/src/i810_dri.c
index 72718d3..fc081ca 100644
--- a/src/i810_dri.c
+++ b/src/i810_dri.c
@@ -295,6 +295,7 @@ I810DRIScreenInit(ScreenPtr pScreen)
unsigned long tom;
drm_handle_t agpHandle;
drm_handle_t dcacheHandle;
+ int major, minor, patch;
int sysmem_size = 0;
int back_size = 0;
unsigned int pitch_idx = 0;
@@ -320,18 +321,14 @@ I810DRIScreenInit(ScreenPtr pScreen)
}
/* Check the DRI version */
- {
- int major, minor, patch;
-
- DRIQueryVersion(major, minor, patch);
- if (major != DRIINFO_MAJOR_VERSION || minor DRIINFO_MINOR_VERSION) {
- xf86DrvMsg(pScreen-myNum, X_ERROR,
- [dri] I810DRIScreenInit failed because of a version mismatch.\n
- [dri] libdri version is %d.%d.%d bug version %d.%d.x is needed.\n
- [dri] Disabling DRI.\n, major, minor, patch,
-DRIINFO_MAJOR_VERSION, DRIINFO_MINOR_VERSION);
- return FALSE;
- }
+ DRIQueryVersion(major, minor, patch);
+ if (major != DRIINFO_MAJOR_VERSION || minor DRIINFO_MINOR_VERSION) {
+ xf86DrvMsg(pScreen-myNum, X_ERROR,
+ [dri] I810DRIScreenInit failed because of a version mismatch.\n
+ [dri] libdri version is %d.%d.%d bug version %d.%d.x is needed.\n
+ [dri] Disabling DRI.\n, major, minor, patch,
+ DRIINFO_MAJOR_VERSION, DRIINFO_MINOR_VERSION);
+ return FALSE;
}
pDRIInfo = DRICreateInfoRec();
@@ -361,12 +358,17 @@ I810DRIScreenInit(ScreenPtr pScreen)
pDRIInfo-ddxDriverMajorVersion = I810_MAJOR_VERSION;
pDRIInfo-ddxDriverMinorVersion = I810_MINOR_VERSION;
pDRIInfo-ddxDriverPatchVersion = I810_PATCHLEVEL;
- pDRIInfo-frameBufferPhysicalAddress = (pointer) pI810-LinearAddr;
- pDRIInfo-frameBufferSize = (((pScrn-displayWidth *
- pScrn-virtualY * pI810-cpp) +
- 4096 - 1) / 4096) * 4096;
+ pDRIInfo-frameBufferPhysicalAddress = (pointer) pI810-LinearAddr;
+ pDRIInfo-frameBufferSize =
+ ROUND_TO_PAGE(pScrn-displayWidth * pScrn-virtualY * pI810-cpp);
pDRIInfo-frameBufferStride = pScrn-displayWidth * pI810-cpp;
+
+#if DRIINFO_MAJOR_VERSION == 5 DRIINFO_MINOR_VERSION = 4
+ if (major == 5 || minor = 4)
+ pDRIInfo-dontMapFrameBuffer = TRUE;
+#endif
+
pDRIInfo-ddxDrawableTableEntry = I810_MAX_DRAWABLES;
if (SAREA_MAX_DRAWABLES I810_MAX_DRAWABLES)
@@ -407,8 +409,9 @@ I810DRIScreenInit(ScreenPtr pScreen)
pDRIInfo-createDummyCtx = TRUE;
pDRIInfo-createDummyCtxPriv = FALSE;
- /* This adds the framebuffer as a drm map *before* we have asked agp
-* to allocate it. Scary stuff, hold on...
+ /* For pre 5.4.0 libdri this adds the framebuffer as a drm map
+* *before* we have asked agp to allocate it. Scary stuff, hold
+* on...
*/
if (!DRIScreenInit(pScreen, pDRIInfo, pI810-drmSubFD)) {
xf86DrvMsg(pScreen-myNum, X_ERROR,
@@ -860,8 +863,21 @@ I810DRIScreenInit(ScreenPtr pScreen)
pI810-auxPitch = i810_pitches[pitch_idx];
pI810-auxPitchBits = i810_pitch_flags[pitch_idx];
pI810-SavedDcacheMem = pI810-DcacheMem;
-
Re: Merging DRI changes
Kristian Høgsberg wrote: Hi, I've finished the changes to the DRI interface that I've been talking about for a while (see #5714). Ian had a look at the DRI driver side of things, and ACK'ed those changes. I've done the X server changes now plus a couple of GLX module cleanups, and I think it's all ready to push: http://gitweb.freedesktop.org/?p=users/krh/mesa.git;a=shortlog;h=dri2 and http://gitweb.freedesktop.org/?p=users/krh/xserver.git;a=shortlog;h=dri2 One thing that's still missing is Alan H's changes to how DRI/DDX maps the front buffer. While the changes above break the DRI interface, they only require an X server and a Mesa update. Alans patches change the device private shared between the DDX and DRI driver and thus requires updating every DRI capable DDX driver in a non-compatible way. Kristian, Just letting you know Alan's on holidays this week, back on Monday. Keith - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Merging DRI changes
Hi, I've finished the changes to the DRI interface that I've been talking about for a while (see #5714). Ian had a look at the DRI driver side of things, and ACK'ed those changes. I've done the X server changes now plus a couple of GLX module cleanups, and I think it's all ready to push: http://gitweb.freedesktop.org/?p=users/krh/mesa.git;a=shortlog;h=dri2 and http://gitweb.freedesktop.org/?p=users/krh/xserver.git;a=shortlog;h=dri2 One thing that's still missing is Alan H's changes to how DRI/DDX maps the front buffer. While the changes above break the DRI interface, they only require an X server and a Mesa update. Alans patches change the device private shared between the DDX and DRI driver and thus requires updating every DRI capable DDX driver in a non-compatible way. I've been trying to understand the change better in order to try to come up with a backwards compatible way to do the same. I think I've found a way to let the DDX driver tell libdri not to map the framebuffer and then do it itself. The problem is that Alans patch also changes the DRI driver side of things to not map the front buffer in the loader but in the driver code, based on extra info from the DDX device private. A compromise that will leave the DDX device private untouched is still require the framebuffer info (handle and size etc) through DRIGetDeviceInfo, but to not map the front buffer in the loader. Instead we just pass the handle and size into the DRI driver (as we do now), and the driver can then do the drmMap(). However, at this point I'm wondering what the intention of the patch is and if my suggested change somehow conflicts with that... help? cheers, Kristian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
