RE: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
How about a mergedfb branch if not the trunk? I'm pretty good about keeping things up to date. I'm not yet an expert with CVS, but it won't take long ;) Alex --- Alexander Stohr [EMAIL PROTECTED] wrote: you would wonder how other developers could enjoy having a look on your updates at the time that they do happen. nothing worse than a driver which is based on that design but is outdated by weeks or even months relative to the top of the tree of your ongoing development. i would suggest having all your works going on in a CVS repository, prefereably some development branch like the texmem one. as the whole discussion takes place here at dri-devel and the major benefits seem to be (at least for me) on the dri project's behalf, i would vote for basing it at the dri's CVS server system. (lets hope that thing is working reliable for the next time.) to clarify, i would not mind having such a tree undergoing deep changes in a short time - anyone who wants can take an older snapshot or do its snapshot himselves. its just the point of sharing will improve any sort of growth here. of course there can be personal reasons like not beeing friend of CVS, having lots of broken code for long times or just the fact that a shared code database does need some sort of merger with other people's code any now and then. my personal expirience is that a compile any now and then plus some people that are testing such a codebase for functionality is a sufficient means for good results. -Alex. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
On Thu, 2003-09-11 at 09:15, Benjamin Herrenschmidt wrote: On Wed, 2003-09-10 at 18:12, Michel Dnzer wrote: On Wed, 2003-09-10 at 17:59, Alex Deucher wrote: Factoring it out is not a problem. the question is what to do with it when I pull it out. create an external external libray like libXMergedFB.so or something like that? I was thinking of creating a new module like shadowfb. what's the preferred method? any existing examples I can look at? Another example is the Xv helper functions which were factored out to programs/Xserver/hw/xfree86/common/xf86xv.c . And broken for big endian last time I tried ;) Mark had to revert nv to use it's built-in functions for BE to work again... The nv driver could adapt the framebuffer aperture byte swapping before calling the common functions as other drivers do. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
I did some basic work on factoring out the common code and discussed it with Thomas Winischhofer (Sis maintainer and driving force behind mergedfb development). He is of the opinion that it is still too early to create a generic API for mergedfb. There is still no consensus on what the final look should be and whether or not we have a flexible enough model right now. Plus there are some new features in the pipeline that may require some reworking of the current common code (absolute offsets and panning domains). It's more of a pain to have to constantly update the common code. So at the moment I guess I'm inclined to agree. thoughts? Alex --- Michel D�nzer [EMAIL PROTECTED] wrote: On Wed, 2003-09-10 at 15:46, Alex Deucher wrote: It seems like a lot of cards have this type of capability and lots of drivers are doing this somewhat independently of one another. Is there some common code that can be abstracted out? (Looking quickly over the code indicates that a big percentage of it looks pretty hw-independent). I agree. Most of it is HW independant. This was discussed several times on the xfree86 devel ML, and everyone agrees that it should be factored out into common code, however, when that will happen is kind of hazy. I thought about trying to do some of the work myself, but I guess we need a consensus on what's the best mergedfb API. the usual 5.0 material response. As a first step, it shouldn't be too much work factoring out the common helper functions, possibly into a new module? Everyone is busy, so I don't know when the commom code would be written, much less an API agreed on. Thomas' sis mergedfb code (which my radeon code is based on) is already in the xfree86 tree. Both of our implementations plus the mga driver share the same mergedfb options so they are consistent. I don't want to write the common code only it have it be a waste of time due to a refactoring of X internals planned for 5.0 or because my API is lacking. I wouldn't worry too much about 5.x yet, that's still in the distant future AFAICT. IMHO the pains that code duplication will cause in the meantime (we've seen over and over that even the tiniest duplication can cause considerable grief) greatly outweigh the potential 'waste' of time factoring out the common code. (As a side note, I'd expect this to be much easier than merging the Radeon 3D drivers :) -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
On Thu, 2003-09-11 at 17:32, Alex Deucher wrote: I did some basic work on factoring out the common code and discussed it with Thomas Winischhofer (Sis maintainer and driving force behind mergedfb development). He is of the opinion that it is still too early to create a generic API for mergedfb. There is still no consensus on what the final look should be and whether or not we have a flexible enough model right now. Plus there are some new features in the pipeline that may require some reworking of the current common code (absolute offsets and panning domains). It's more of a pain to have to constantly update the common code. And it's less painful to do the same changes in all the drivers, possibly introducing inconsistencies? -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
On Wed, 2003-09-10 at 18:12, Michel Dänzer wrote: On Wed, 2003-09-10 at 17:59, Alex Deucher wrote: Factoring it out is not a problem. the question is what to do with it when I pull it out. create an external external libray like libXMergedFB.so or something like that? I was thinking of creating a new module like shadowfb. what's the preferred method? any existing examples I can look at? Another example is the Xv helper functions which were factored out to programs/Xserver/hw/xfree86/common/xf86xv.c . And broken for big endian last time I tried ;) Mark had to revert nv to use it's built-in functions for BE to work again... Ben. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
I did some basic work on factoring out the common code and discussed it with Thomas Winischhofer (Sis maintainer and driving force behind mergedfb development). He is of the opinion that it is still too early to create a generic API for mergedfb. There is still no consensus on what the final look should be and whether or not we have a flexible enough model right now. Plus there are some new features in the pipeline that may require some reworking of the current common code (absolute offsets and panning domains). It's more of a pain to have to constantly update the common code. So at the moment I guess I'm inclined to agree. thoughts? Alex you would wonder how other developers could enjoy having a look on your updates at the time that they do happen. nothing worse than a driver which is based on that design but is outdated by weeks or even months relative to the top of the tree of your ongoing development. i would suggest having all your works going on in a CVS repository, prefereably some development branch like the texmem one. as the whole discussion takes place here at dri-devel and the major benefits seem to be (at least for me) on the dri project's behalf, i would vote for basing it at the dri's CVS server system. (lets hope that thing is working reliable for the next time.) to clarify, i would not mind having such a tree undergoing deep changes in a short time - anyone who wants can take an older snapshot or do its snapshot himselves. its just the point of sharing will improve any sort of growth here. of course there can be personal reasons like not beeing friend of CVS, having lots of broken code for long times or just the fact that a shared code database does need some sort of merger with other people's code any now and then. my personal expirience is that a compile any now and then plus some people that are testing such a codebase for functionality is a sufficient means for good results. -Alex. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
--- Keith Whitwell [EMAIL PROTECTED] wrote: Alex Deucher wrote: looks like the post size limit ate my first attempt to post this. Anyway, I was finally able to access DRI cvs (from dri.freedesktop.org), so I pulled the latest tree and created a radeon mergedfb patch against it. I've done some testing and it seems to work fine. The patch only touches the 2D driver. I talked to Kevin E. Marin about merging it and he suggested I get it into the DRI tree. I think this patch adds a useful feature and I'd like to see it get merged. Thoughts? I'd like to see something like this merged, definitely. Your code looks fine on a first pass, my only question is whether this is something that can be done largely or partly in shared device-independent code, and just have drivers hook that code in. It seems like a lot of cards have this type of capability and lots of drivers are doing this somewhat independently of one another. Is there some common code that can be abstracted out? (Looking quickly over the code indicates that a big percentage of it looks pretty hw-independent). I agree. Most of it is HW independant. This was discussed several times on the xfree86 devel ML, and everyone agrees that it should be factored out into common code, however, when that will happen is kind of hazy. I thought about trying to do some of the work myself, but I guess we need a consensus on what's the best mergedfb API. the usual 5.0 material response. Also the Pseudo-xinerama stuff should also be folded into the next version of the real xinerama extension, but once again that's 5.0 material. Everyone is busy, so I don't know when the commom code would be written, much less an API agreed on. Thomas' sis mergedfb code (which my radeon code is based on) is already in the xfree86 tree. Both of our implementations plus the mga driver share the same mergedfb options so they are consistent. I don't want to write the common code only it have it be a waste of time due to a refactoring of X internals planned for 5.0 or because my API is lacking. And the other question is why didn't Kevin want it in the XFree86 tree? Is there going to be a problem merging this code at some point in the future, or did he just think DRI was a natural home for it? Just curious really... He thought since it allowed for 3D in a dualhead configuration, it would be a better fit in the DRI tree. that's probably why most people would use it since xinerama works well for 2D-only dualhead. Thanks, Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
On Wed, 2003-09-10 at 15:46, Alex Deucher wrote: It seems like a lot of cards have this type of capability and lots of drivers are doing this somewhat independently of one another. Is there some common code that can be abstracted out? (Looking quickly over the code indicates that a big percentage of it looks pretty hw-independent). I agree. Most of it is HW independant. This was discussed several times on the xfree86 devel ML, and everyone agrees that it should be factored out into common code, however, when that will happen is kind of hazy. I thought about trying to do some of the work myself, but I guess we need a consensus on what's the best mergedfb API. the usual 5.0 material response. As a first step, it shouldn't be too much work factoring out the common helper functions, possibly into a new module? Everyone is busy, so I don't know when the commom code would be written, much less an API agreed on. Thomas' sis mergedfb code (which my radeon code is based on) is already in the xfree86 tree. Both of our implementations plus the mga driver share the same mergedfb options so they are consistent. I don't want to write the common code only it have it be a waste of time due to a refactoring of X internals planned for 5.0 or because my API is lacking. I wouldn't worry too much about 5.x yet, that's still in the distant future AFAICT. IMHO the pains that code duplication will cause in the meantime (we've seen over and over that even the tiniest duplication can cause considerable grief) greatly outweigh the potential 'waste' of time factoring out the common code. (As a side note, I'd expect this to be much easier than merging the Radeon 3D drivers :) -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
On Wed, 10 Sep 2003, Alex Deucher wrote: --- Keith Whitwell [EMAIL PROTECTED] wrote: And the other question is why didn't Kevin want it in the XFree86 tree? Is there going to be a problem merging this code at some point in the future, or did he just think DRI was a natural home for it? Just curious really... He thought since it allowed for 3D in a dualhead configuration, it would be a better fit in the DRI tree. that's probably why most people would use it since xinerama works well for 2D-only dualhead. I may be imagining this, but in my experience mergedfb gives better performance (smoother) when solid-dragging a window from one head to the other, for example. So it's better for 2D too :) -- Bill Gallafent. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
Factoring it out is not a problem. the question is what to do with it when I pull it out. create an external external libray like libXMergedFB.so or something like that? what's the preferred method? any existing examples I can look at? Alex --- Michel Dänzer [EMAIL PROTECTED] wrote: As a first step, it shouldn't be too much work factoring out the common helper functions, possibly into a new module? ... I wouldn't worry too much about 5.x yet, that's still in the distant future AFAICT. IMHO the pains that code duplication will cause in the meantime (we've seen over and over that even the tiniest duplication can cause considerable grief) greatly outweigh the potential 'waste' of time factoring out the common code. (As a side note, I'd expect this to be much easier than merging the Radeon 3D drivers :) __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] radeon mergedfb support for DRI CVS
On Wed, 2003-09-10 at 17:59, Alex Deucher wrote: Factoring it out is not a problem. the question is what to do with it when I pull it out. create an external external libray like libXMergedFB.so or something like that? I was thinking of creating a new module like shadowfb. what's the preferred method? any existing examples I can look at? Another example is the Xv helper functions which were factored out to programs/Xserver/hw/xfree86/common/xf86xv.c . -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
