From: Felix <fx...@gm...> - 2004-07-30 22:06:02
|
Hi, I'm looking into porting the savage driver to the new interface so it can be built in the Mesa tree. I took a look at the r128 and mga drivers for reference. I noticed that the old drivers (I still have a savage-2-0-0-branch lying around) used to check the DRI/DDX/DRM versions (using driCheckDriDdxDrmVersions) in the CreateScreen or InitDriver function. This check is gone in the current drivers and replaced by a version check in the CreateNewScreen function (using driCheckDriDdxDrmVersions2). However, as far as I understand this function is only called if the driver is loaded by a new libGL. When the driver is built without NEW_INTERFACE_ONLY and loaded by an old libGL then there are no version checks any more. Am I missing something? Regards, Felix | Felix K=FChling <fx...@gm...> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: Ian R. <id...@us...> - 2004-07-30 22:24:17
|
Felix K=FChling wrote: > I'm looking into porting the savage driver to the new interface so it > can be built in the Mesa tree. I took a look at the r128 and mga driver= s > for reference. I noticed that the old drivers (I still have a > savage-2-0-0-branch lying around) used to check the DRI/DDX/DRM version= s > (using driCheckDriDdxDrmVersions) in the CreateScreen or InitDriver > function. This check is gone in the current drivers and replaced by a > version check in the CreateNewScreen function (using > driCheckDriDdxDrmVersions2). However, as far as I understand this > function is only called if the driver is loaded by a new libGL. When th= e > driver is built without NEW_INTERFACE_ONLY and loaded by an old libGL > then there are no version checks any more. Am I missing something? An old libGL will call the driver's CreateScreen function. This=20 function calls __driUtilCreateScreen, which does the extra work that is=20 now done in a new libGL, then calls the driver's CreateNewScreen.=20 Whether you're using an old libGL or a new one, you eventually get to=20 CreateNewScreen. |
From: Felix <fx...@gm...> - 2004-07-30 23:15:13
|
On Fri, 30 Jul 2004 15:24:03 -0700 Ian Romanick <id...@us...> wrote: > Felix K=FChling wrote: >=20 > > I'm looking into porting the savage driver to the new interface so it > > can be built in the Mesa tree. I took a look at the r128 and mga drivers > > for reference. I noticed that the old drivers (I still have a > > savage-2-0-0-branch lying around) used to check the DRI/DDX/DRM versions > > (using driCheckDriDdxDrmVersions) in the CreateScreen or InitDriver > > function. This check is gone in the current drivers and replaced by a > > version check in the CreateNewScreen function (using > > driCheckDriDdxDrmVersions2). However, as far as I understand this > > function is only called if the driver is loaded by a new libGL. When the > > driver is built without NEW_INTERFACE_ONLY and loaded by an old libGL > > then there are no version checks any more. Am I missing something? >=20 > An old libGL will call the driver's CreateScreen function. This=20 > function calls __driUtilCreateScreen, which does the extra work that is=20 > now done in a new libGL, then calls the driver's CreateNewScreen.=20 > Whether you're using an old libGL or a new one, you eventually get to=20 > CreateNewScreen. Not quite. __driUtilCreateScreen does call __driUtilCreateNewScreen, but from there you never get back to the driver's CreateNewScreen function. New interface drivers call __driUtilCreateNewScreen from driverCreateNewScreen, not the other way around. And the savage driver, which is not ported yet, doesn't even have a driverCreateNewScreen function. So I still believe a new driver loaded by an old libGL never checks the DRI/DDX/DRM versions. I verified this with the radeon driver by inserting a debug printf at the start of __driCreateNewScreen. Then I ran glxgears once with a new libGL and once with an old one (from XFree86 4.3). In the first case I saw the debug output, in the second case I didn't. I guess the version check in the InitDriver/CreateScreen function is still needed for the old interface. <OT> First I tried to verify my claims by setting a breakpoint in gdb using an old libGL. But unfortunately I can't debug DRI apps any more. I get an error message like this as soon as I try to run the app: Error while reading shared library symbols: Cannot find new threads: capability not available Cannon find user-level thread for LWP xxxx: capability not available I guess I'd have to upgrade gdb. The current gdb version on this box is 5.3. </OT> Felix | Felix K=FChling <fx...@gm...> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | |
From: Ian R. <id...@us...> - 2004-07-30 23:59:50
|
Felix K=FChling wrote: > On Fri, 30 Jul 2004 15:24:03 -0700 > Ian Romanick <id...@us...> wrote: >=20 >>An old libGL will call the driver's CreateScreen function. This=20 >>function calls __driUtilCreateScreen, which does the extra work that is= =20 >>now done in a new libGL, then calls the driver's CreateNewScreen.=20 >>Whether you're using an old libGL or a new one, you eventually get to=20 >>CreateNewScreen. >=20 > Not quite. __driUtilCreateScreen does call __driUtilCreateNewScreen, bu= t > from there you never get back to the driver's CreateNewScreen function. > New interface drivers call __driUtilCreateNewScreen from > driverCreateNewScreen, not the other way around. And the savage driver, > which is not ported yet, doesn't even have a driverCreateNewScreen > function. So I still believe a new driver loaded by an old libGL never > checks the DRI/DDX/DRM versions. Hmm...I looked at the code in __driUtilCreateScreen in dri_util.c. I'm=20 inclined to say that the call to __driUtilCreateNewScreen should be a=20 call to __driCreateNewScreen instead. I don't want to have any more=20 code than absolutely necessary in the "old" API compatibility path. I=20 fully expect that code to get less and less testing as time goes on.=20 I'd rather not have bugs creep in. In any case, could you file a bug on this in X.org bugzilla? This code=20 is currently in the X.org tree, and there's a release coming up soon. ;) > I verified this with the radeon driver by inserting a debug printf at > the start of __driCreateNewScreen. Then I ran glxgears once with a new > libGL and once with an old one (from XFree86 4.3). In the first case I > saw the debug output, in the second case I didn't. >=20 > I guess the version check in the InitDriver/CreateScreen function is > still needed for the old interface. |
From: Jon S. <jon...@ya...> - 2004-07-31 00:33:23
|
While you're in there messing with CreateScreen what was the decision on the framebuffer parameter in CreateNewScreen? Is this something that should be deleted before things get shipped? ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail |
From: M. B. <ser...@ne...> - 2004-07-31 00:23:02
|
On Fri, 2004-07-30 at 23:08, Felix K=FChling wrote:=20 > Hi, >=20 > I'm looking into porting the savage driver to the new interface so it > can be built in the Mesa tree. I took a look at the r128 and mga drivers > for reference. I noticed that the old drivers (I still have a > savage-2-0-0-branch lying around) used to check the DRI/DDX/DRM versions > (using driCheckDriDdxDrmVersions) in the CreateScreen or InitDriver > function. This check is gone in the current drivers and replaced by a > version check in the CreateNewScreen function (using > driCheckDriDdxDrmVersions2). However, as far as I understand this > function is only called if the driver is loaded by a new libGL. When the > driver is built without NEW_INTERFACE_ONLY and loaded by an old libGL > then there are no version checks any more. Am I missing something? >=20 > Regards, > Felix I couldn't help much, but comparing drm of xorg tree with trunk tree ( diff -rq trunk/drm/ xorgcvs/build/extras/drm/ ) The differences seems only cosmetic, so I guess the drm is equal. Only DDX has to be ported, IIRC Alex Deucher has to warning on this matter. I can try help you, on testing or in compile problems, you can send to me some patches to test on.=20 Best regards, --=20 S=E9rgio M. B. |
From: Alex D. <ale...@gm...> - 2004-07-31 05:09:26
|
On Sat, 31 Jul 2004 01:22:45 +0100, S=E9rgio Monteiro Basto <ser...@ne...> wrote: > On Fri, 2004-07-30 at 23:08, Felix K=FChling wrote: > > Hi, > > > > I'm looking into porting the savage driver to the new interface so it > > can be built in the Mesa tree. I took a look at the r128 and mga driver= s > > for reference. I noticed that the old drivers (I still have a > > savage-2-0-0-branch lying around) used to check the DRI/DDX/DRM version= s > > (using driCheckDriDdxDrmVersions) in the CreateScreen or InitDriver > > function. This check is gone in the current drivers and replaced by a > > version check in the CreateNewScreen function (using > > driCheckDriDdxDrmVersions2). However, as far as I understand this > > function is only called if the driver is loaded by a new libGL. When th= e > > driver is built without NEW_INTERFACE_ONLY and loaded by an old libGL > > then there are no version checks any more. Am I missing something? > > > > Regards, > > Felix >=20 > I couldn't help much, but comparing drm of xorg tree with trunk tree ( > diff -rq trunk/drm/ xorgcvs/build/extras/drm/ ) > The differences seems only cosmetic, so I guess the drm is equal. Only > DDX has to be ported, IIRC Alex Deucher has to warning on this matter. unless someone beats me to it, I'll try and merge the savage DDX fron the DRI into xorg. I'm not exactly sure when I'll get to it, have to see how my free time pans out. I've got a few other patches for the savage DDX I've been working on as well. Alex >=20 > I can try help you, on testing or in compile problems, you can send to > me some patches to test on. >=20 > Best regards, > -- >=20 > S=E9rgio M. B. >=20 >=20 > |