Re: RFC: libdrm repo
On Sunday 29 November 2009 19:51:55 Robert Noland wrote: > On Sun, 2009-11-29 at 15:36 -0800, vehemens wrote: > > I believe that moving away from the current model makes it more > > difficult > > to "... spread the burden ...", hence my objections. If you want to > > call > > that ranting or complaining, so be it. > > We no longer get to share the burden with the much larger group of linux > devs directly. That *was* my primary objection to > reorganizing/abandoning drm git in the first place. Yes, I'm a little > bitter about it when I have to recite how we got where we are, but it's > done, we lost, move on. > > As for the FreeBSD code, generally each subsystem has one primary > responsible individual. For drm, that person is me. Anyone is more > than welcome to submit patches for review by either sending them to the > mailing lists, sending them to me, or filing a PR. I've accepted > patches from you in the past and I will continue to do so, if you choose > to send them. > > At last check, you had not yet been granted commit privileges for drm > git, so your path was still to submit patches to the mailing list, or > directly to me. So, I don't quite get how it makes a difference to you > if you submit patches based on drm git or against the FreeBSD src tree. > For anyone to grant you commit privs, either on fd.o or FreeBSD.org (or > most any other repo for that matter) you are going to have to > demonstrate a track record of submitting reasonable patches and a > willingness to work and get along within that community of developers. > It has been more than a year since you submitted anything to me that was > coherent and usable. This tar file that you sent me is dated 09/12/09, > but despite your arguments, it isn't currently in a form that makes it > reasonable to extract the good changes from the bad. I look at diffs > pretty much every day. Robert it no longer matters. I'm going to concide defeat and switch to Linux. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 15:36:51 Adam K Kirchhoff wrote: > On Sunday 29 November 2009 18:54:31 vehemens wrote: > > On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote: > > > On Sunday 29 November 2009 14:16:13 vehemens wrote: > > > > > > [snip] > > > > > > > Your missing the point of using a development structure which > > > > supports collobration. > > > > > > [snip] > > > > > > > The difference is that you are the only one doing the work now. > > > > > > [snip] > > > > > > > Again, your missing the point of using a development structure which > > > > supports collobration. > > > > > > [snip] > > > > > > > It hasn't moved "... well beyond what was in drm git." If you > > > > believe otherwise, your only fooling yourself. > > > > > > [snip] > > > > > > > See above comments. > > > > > > Yes, you have made it abundantly clear that you are in favor of having > > > a centralized repository for all DRM development. The fact is, that's > > > not happening now and is not going to happen. That used to be the > > > case, but the linux DRM developers did not see an advantage to that for > > > themselves, and though rnoland was unhappy with the decision (because > > > it made his job harder), the linux DRM developers did what they felt > > > was best. > > > > You assuming what what good for Linux for a developer, is also good for a > > BSD developer. As for making rnoland's job harder, it was his choice. > > Nice try, but I am making no such assumptions. It was not rnoland's choice > to stop having the linux DRM developers stop using a centralized repository > for all DRM code. He was quite clearly opposed to it and did not consider > it a good choice. You missing the point as is rnoland. Just because the linux DRM developers stopped using a centralized repository, didn't mean FreeBSD shouldn't as the intial integration work would be still shared reducing the burden on any one person. The approach taken by rnoland however was to shift all the work to himself. > > > Since then, rnoland has made significant progress porting the linux > > > specific changes over to FreeBSD. If you don't believe the changes > > > he's made in the FreeBSD source tree go 'well beyond' what had been in > > > mesa/drm on freedesktop git then you are fooling yourself. Frankly, if > > > I were Robert, I would be offended by that statement you made. > > > > I've diffed the code. Suggest that you do the same and see if you can > > still make the same statements. > > r6xx/r7xx DRM code, alone, pushes FreeBSD DRM "well beyond" what was in > mesa/drm on freedesktop. As for FreeBSD r6xx/r7xx DRM, here's an email on the subject which is how I remember the events. http://lists.freebsd.org/pipermail/freebsd-x11/2009-February/007624.html -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote: > On Sunday 29 November 2009 14:16:13 vehemens wrote: > > [snip] > > > Your missing the point of using a development structure which supports > > collobration. > > [snip] > > > The difference is that you are the only one doing the work now. > > [snip] > > > Again, your missing the point of using a development structure which > > supports collobration. > > [snip] > > > It hasn't moved "... well beyond what was in drm git." If you believe > > otherwise, your only fooling yourself. > > [snip] > > > See above comments. > > Yes, you have made it abundantly clear that you are in favor of having a > centralized repository for all DRM development. The fact is, that's not > happening now and is not going to happen. That used to be the case, but > the linux DRM developers did not see an advantage to that for themselves, > and though rnoland was unhappy with the decision (because it made his job > harder), the linux DRM developers did what they felt was best. You assuming what what good for Linux for a developer, is also good for a BSD developer. As for making rnoland's job harder, it was his choice. > Since then, rnoland has made significant progress porting the linux > specific changes over to FreeBSD. If you don't believe the changes he's > made in the FreeBSD source tree go 'well beyond' what had been in mesa/drm > on freedesktop git then you are fooling yourself. Frankly, if I were > Robert, I would be offended by that statement you made. I've diffed the code. Suggest that you do the same and see if you can still make the same statements. > As has been said time and again, the kernel specific code in mesa/drm > serves no purpose other than providing a historical log of the DRM > development from that time, so there was no harm in pulling it. The > FreeBSD DRM code follows the same development model as the rest of FreeBSD, > and I have a hard time believing that such a model doesn't support > collaboration. That is certainly an accusation I've never once heard made > against the FreeBSD project in recent years till just now. If one stashes his/her development code where few if any can get at it, I don't consider that collaboration. > Now, the changes are made, and what's done is done. Can we please just > move on? I was going to move along, but I felt your email had so many errors, I couldn't let it got by. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 10:39:34 Maarten Maathuis wrote: > I enjoy playing the devils advocate occasionally, so take this with a > grain of salt. > > My understanding is that there are roughly 3 bsd kernels that support > drm userspace interface(free*, open* and netbsd?), each has 1 or 2 > maintainers. For better or worse the linux guys/girls have gone their > own way. > > As far as i can tell kernel driver complexity has gone up in recent > time, to the point where nouveau (which is a relatively small group of > people too) has done the same (=move to a linux kernel tree) to avoid > the significant burden of backporting. Unless the 3 bsd kernels are > very similar i do not see how you expect to keep up. > > Instead of ranting you should ask yourself if it is even possible to > unify the drm code for all forms of bsd. Accept that the majority of > developers (which use linux as far as i know) have moved away from the > development model that you prefer. As the devils advocate i can say > that the gain for linux-drm from bsd-drm is not worth the effort of > the old development model, you are (unfortunately) forced to do more > work. > > Robert has accepted the reality, all you can try to do is spread the > burden across all the bsd's. The way you're being treated is a result > from the harsh reality that stems from the stalemate that the previous > development model caused. No amount of complaining is going to change > the fact that some people don't care about bsd. I believe that moving away from the current model makes it more difficult to "... spread the burden ...", hence my objections. If you want to call that ranting or complaining, so be it. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 07:07:41 Robert Noland wrote: > On Sat, 2009-11-28 at 20:40 -0800, vehemens wrote: > > On Saturday 28 November 2009 16:21:58 Robert Noland wrote: > > > On Sat, 2009-11-28 at 13:38 -0800, vehemens wrote: > > > > On Saturday 28 November 2009 10:41:39 Robert Noland wrote: > > > > > On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: > > > > > > On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: > > > > > > > On Sun, Nov 22, 2009 at 7:10 PM, vehemens > > > > > > > > > > > wrote: > > > > > > > > On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: > > > > > > > >> > I see that you deleted bsd-core dispite the requests of a > > > > > > > >> > number of people that you do not. > > > > > > > >> > > > > > > > >> Its git, nobody has touched any of it in ages, and none of > > > > > > > >> the BSD maintainers used it, you can just get it back by > > > > > > > >> branching from the commit before its removal, if you think > > > > > > > >> revival is needed, don't bring back linux-core when you do > > > > > > > >> please. > > > > > > > > > > > > > > > > I already told the both of you that I was planning to use it > > > > > > > > on IRC, I just haven't had time to put anything in. > > > > > > > > > > > > > > > > In addition, he's asking for a repro to libdrm. The way I > > > > > > > > see it, is there were two choices: > > > > > > > > 1) repro to libdrm, add the changes, not piss people off > > > > > > > > 2) add the changes, repro to libdrm, piss people off > > > > > > > > > > > > > > I think we pissed one person off, not people, as I said, there > > > > > > > are two people registered as BSD maintainers for drm code, oga > > > > > > > and rnoland, neither of them cared. I'm not sure what value the > > > > > > > codebase has if neither Free or OpenBSD are going to use it. > > > > > > > > > > > > You pissed a number of people off, but the difference with me is > > > > > > that I'm not letting either of you get away with it. > > > > > > > > > > > > There are more then two BSD maintainers, and your statement that > > > > > > neither of them cared is not correct. > > > > > > > > > > Don't get me wrong here, I don't like the current state of things, > > > > > but given current drm development practices, this change was > > > > > irrelevant. I was a bit frustrated at the build breakage for > > > > > libdrm, but krh and I worked through that and it is now resolved. > > > > > > > > > > While you have provided me with patches in the past, (which are > > > > > much appreciated) I have not seen consistent or relevant work > > > > > lately, so it really isn't clear to me how this is a big deal. > > > > > Given the nature of git, you could just branch your local repo > > > > > before that commit, though patches based on the old repo are > > > > > becoming increasingly difficult to merge into real code. > > > > > > > > I haven't published any of my work recently, but that doesn't mean I > > > > haven't done anything that I would like to share. Not sure why you > > > > feel this is important however. > > > > > > Because unpublished work doesn't exist That goes for the work that > > > I've done that isn't yet published as well. Until it is in the hands > > > of someone besides yourself it is irrelevant. > > > > Thats the whole point of having a public respository. How else can one > > publish? > > Again, there is nothing that prevents you from publishing your version > of the drm repo, though I don't see the point. Your missing the point of using a development structure which supports collobration. > > > > I gave you a number of suggestions in private emails on how to fix > > > > problems such as the merging issue and you were unwilling to take > > > > them. > > > > > > I'm not sure which issue you are referri
Re: RFC: libdrm repo
On Sunday 29 November 2009 00:31:17 Daniel Stone wrote: > Hi, > > On Sat, Nov 28, 2009 at 08:40:55PM -0800, vehemens wrote: > > On Saturday 28 November 2009 16:21:58 Robert Noland wrote: > > > Because unpublished work doesn't exist That goes for the work that > > > I've done that isn't yet published as well. Until it is in the hands > > > of someone besides yourself it is irrelevant. > > > > Thats the whole point of having a public respository. How else can one > > publish? > > gitorious, github, people.fd.o, freebsd.org public_html, etc, etc. Well I meant in the context of the existing structure, not starting a brand new one. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Saturday 28 November 2009 16:21:58 Robert Noland wrote: > On Sat, 2009-11-28 at 13:38 -0800, vehemens wrote: > > On Saturday 28 November 2009 10:41:39 Robert Noland wrote: > > > On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: > > > > On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: > > > > > On Sun, Nov 22, 2009 at 7:10 PM, vehemens wrote: > > > > > > On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: > > > > > >> > I see that you deleted bsd-core dispite the requests of a > > > > > >> > number of people that you do not. > > > > > >> > > > > > >> Its git, nobody has touched any of it in ages, and none of the > > > > > >> BSD maintainers used it, you can just get it back by branching > > > > > >> from the commit before its removal, if you think revival is > > > > > >> needed, don't bring back linux-core when you do please. > > > > > > > > > > > > I already told the both of you that I was planning to use it on > > > > > > IRC, I just haven't had time to put anything in. > > > > > > > > > > > > In addition, he's asking for a repro to libdrm. The way I see > > > > > > it, is there were two choices: > > > > > > 1) repro to libdrm, add the changes, not piss people off > > > > > > 2) add the changes, repro to libdrm, piss people off > > > > > > > > > > I think we pissed one person off, not people, as I said, there are > > > > > two people registered as BSD maintainers for drm code, oga and > > > > > rnoland, neither of them cared. I'm not sure what value the > > > > > codebase has if neither Free or OpenBSD are going to use it. > > > > > > > > You pissed a number of people off, but the difference with me is that > > > > I'm not letting either of you get away with it. > > > > > > > > There are more then two BSD maintainers, and your statement that > > > > neither of them cared is not correct. > > > > > > Don't get me wrong here, I don't like the current state of things, but > > > given current drm development practices, this change was irrelevant. I > > > was a bit frustrated at the build breakage for libdrm, but krh and I > > > worked through that and it is now resolved. > > > > > > While you have provided me with patches in the past, (which are much > > > appreciated) I have not seen consistent or relevant work lately, so it > > > really isn't clear to me how this is a big deal. Given the nature of > > > git, you could just branch your local repo before that commit, though > > > patches based on the old repo are becoming increasingly difficult to > > > merge into real code. > > > > I haven't published any of my work recently, but that doesn't mean I > > haven't done anything that I would like to share. Not sure why you feel > > this is important however. > > Because unpublished work doesn't exist That goes for the work that > I've done that isn't yet published as well. Until it is in the hands of > someone besides yourself it is irrelevant. Thats the whole point of having a public respository. How else can one publish? > > I gave you a number of suggestions in private emails on how to fix > > problems such as the merging issue and you were unwilling to take them. > > I'm not sure which issue you are referring to right now. But if you > mean trying to backport the work of Intel, ATI/AMD and nouveau into a > repository that all of the above have now abandoned, none who currently > have commit to the drm repo are willing or able to take on that task. > > Did you miss my plea's, rants and attempts to make valid arguments not > to reorganize/abandon drm in the first place? Unfortunately, we lost > that battle. It only served to increase the complexity and workload > that I am faced with. However, since every major vendor has now pulled > out and maintains a private linux repo for their code, the code that > lived in drm git was stale, and not terribly useful for anything other > than historical purposes. First you say abandoning the respository increased your workload, then you say it wasn't useful. Which is it? > If you are referring to the patches/diffs that you have sent me, then I > have always appreciated the work that you have done. The last batch of > stuff that you sent me, however w
Re: RFC: libdrm repo
On Saturday 28 November 2009 13:44:53 Dave Airlie wrote: > > I haven't published any of my work recently, but that doesn't mean I > > haven't done anything that I would like to share. Not sure why you feel > > this is important however. > > > > I gave you a number of suggestions in private emails on how to fix > > problems such as the merging issue and you were unwilling to take them. > > > > The whole point of having a public repository for code is collaboration > > that it allows. You seem to of lost sight of this goal. > > > > If you are unwilling or unable to do the work your self, you shouldn't > > prevent others from doing so. > > You don't feel sending patches and having integration/testing phases with > the tree users use is a good process? shared repos are good, but they do > seem to lead to a commit first, review later (if at all) mentality. I think "... that sending patches and having integration/testing phases with the tree users ... is a good process ...". Have to agree that the ".. commit first, review later (if at all) mentality." is a bit of problem sometimes. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Saturday 28 November 2009 10:41:39 Robert Noland wrote: > On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: > > On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: > > > On Sun, Nov 22, 2009 at 7:10 PM, vehemens wrote: > > > > On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: > > > >> > I see that you deleted bsd-core dispite the requests of a number > > > >> > of people that you do not. > > > >> > > > >> Its git, nobody has touched any of it in ages, and none of the BSD > > > >> maintainers used it, you can just get it back by branching from the > > > >> commit before its removal, if you think revival is needed, don't > > > >> bring back linux-core when you do please. > > > > > > > > I already told the both of you that I was planning to use it on IRC, > > > > I just haven't had time to put anything in. > > > > > > > > In addition, he's asking for a repro to libdrm. The way I see it, is > > > > there were two choices: > > > > 1) repro to libdrm, add the changes, not piss people off > > > > 2) add the changes, repro to libdrm, piss people off > > > > > > I think we pissed one person off, not people, as I said, there are two > > > people registered as BSD maintainers for drm code, oga and rnoland, > > > neither of them cared. I'm not sure what value the codebase has if > > > neither Free or OpenBSD are going to use it. > > > > You pissed a number of people off, but the difference with me is that I'm > > not letting either of you get away with it. > > > > There are more then two BSD maintainers, and your statement that neither > > of them cared is not correct. > > Don't get me wrong here, I don't like the current state of things, but > given current drm development practices, this change was irrelevant. I > was a bit frustrated at the build breakage for libdrm, but krh and I > worked through that and it is now resolved. > > While you have provided me with patches in the past, (which are much > appreciated) I have not seen consistent or relevant work lately, so it > really isn't clear to me how this is a big deal. Given the nature of > git, you could just branch your local repo before that commit, though > patches based on the old repo are becoming increasingly difficult to > merge into real code. I haven't published any of my work recently, but that doesn't mean I haven't done anything that I would like to share. Not sure why you feel this is important however. I gave you a number of suggestions in private emails on how to fix problems such as the merging issue and you were unwilling to take them. The whole point of having a public repository for code is collaboration that it allows. You seem to of lost sight of this goal. If you are unwilling or unable to do the work your self, you shouldn't prevent others from doing so. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: > On Sun, Nov 22, 2009 at 7:10 PM, vehemens wrote: > > On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: > >> > I see that you deleted bsd-core dispite the requests of a number of > >> > people that you do not. > >> > >> Its git, nobody has touched any of it in ages, and none of the BSD > >> maintainers used it, you can just get it back by branching from the > >> commit before its removal, if you think revival is needed, don't bring > >> back linux-core when you do please. > > > > I already told the both of you that I was planning to use it on IRC, I > > just haven't had time to put anything in. > > > > In addition, he's asking for a repro to libdrm. The way I see it, is > > there were two choices: > > 1) repro to libdrm, add the changes, not piss people off > > 2) add the changes, repro to libdrm, piss people off > > I think we pissed one person off, not people, as I said, there are two > people registered as BSD maintainers for drm code, oga and rnoland, > neither of them cared. I'm not sure what value the codebase has if > neither Free or OpenBSD are going to use it. You pissed a number of people off, but the difference with me is that I'm not letting either of you get away with it. There are more then two BSD maintainers, and your statement that neither of them cared is not correct. Suggest that you actually read the emails and IRC comments. Your lack of understanding on the value of the codebase is not in general my problem, except when you impact myself and others as you have done this time. > Why bother adding code to a common tree that no operating system > has any intention of shipping ever. This simply isn't true. Please don't make statements that are obviously false. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: > > I see that you deleted bsd-core dispite the requests of a number of > > people that you do not. > > Its git, nobody has touched any of it in ages, and none of the BSD > maintainers used it, you can just get it back by branching from the commit > before its removal, if you think revival is needed, don't bring back > linux-core when you do please. I already told the both of you that I was planning to use it on IRC, I just haven't had time to put anything in. In addition, he's asking for a repro to libdrm. The way I see it, is there were two choices: 1) repro to libdrm, add the changes, not piss people off 2) add the changes, repro to libdrm, piss people off I don't see how you think choice #2 (the one taken) was the right one. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Friday 20 November 2009 14:20:41 Kristian Høgsberg wrote: > 2009/11/19 Eric Anholt : > > On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: > >> 2009/11/6 Kristian Høgsberg : > >> > Hi, > >> > > >> > This has come up a few time and it's something I think makes a lot of > >> > sense. Since all driver development (afaik) now happens in linux > >> > kernel tree, it makes sense to drop the driver bits from the drm.git > >> > repo. > >> > >> Ok, here's an update to the proposal. I've rebased the libdrm branch > >> in people.freedesktop.org/~krh/libdrm.git to include a copy of > >> $kernel_source/usr/include/drm as a toplevel include/drm directory in > >> git. I also added a makefile rule to copy a new version of the > >> headers from a kernel git repo and commit it with a message describing > >> the version it was copied from. The location of the kernel repo is > >> given at ./configure time with the --with-kernel-source argument. > >> > >> By adding the makefile rule, I'd like to encourage people to not hand > >> edit the headers and to commit updates of the header files > >> independently from other changes. And of course, updates to the > >> headers should still follow the rules we have now; only copy over new > >> changes once they're in drm-next (I think, or is that in Linus' > >> tree?). > >> > >> Anyway, I think this should address the concerns raised in the thread > >> and if there's no other problems, I can put this into place today. > >> I'll merge the couple of changes on master since I branched for this > >> work and I'll put a mesa/drm.git symlink in place to point to > >> libdrm.git. > > > > Awesome. Just a touchup to the README to reflect the current state > > seems to be needed. > > Done and pushed. I left the repo as mesa/drm, but I think it makes > sense to move it to be a toplevel repo and rename it libdrm. I don't > have the admin-fu to that myself so I'll need somebody with those > skills to do that for me. > I see that you deleted bsd-core dispite the requests of a number of people that you do not. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Tuesday 17 November 2009 08:33:30 Kristian Høgsberg wrote: > 2009/11/6 Kristian Høgsberg : > > Hi, > > > > This has come up a few time and it's something I think makes a lot of > > sense. Since all driver development (afaik) now happens in linux > > kernel tree, it makes sense to drop the driver bits from the drm.git > > repo. > > Ok, here's an update to the proposal. I've rebased the libdrm branch > in people.freedesktop.org/~krh/libdrm.git to include a copy of > $kernel_source/usr/include/drm as a toplevel include/drm directory in > git. I also added a makefile rule to copy a new version of the > headers from a kernel git repo and commit it with a message describing > the version it was copied from. The location of the kernel repo is > given at ./configure time with the --with-kernel-source argument. > > By adding the makefile rule, I'd like to encourage people to not hand > edit the headers and to commit updates of the header files > independently from other changes. And of course, updates to the > headers should still follow the rules we have now; only copy over new > changes once they're in drm-next (I think, or is that in Linus' > tree?). > > Anyway, I think this should address the concerns raised in the thread > and if there's no other problems, I can put this into place today. > I'll merge the couple of changes on master since I branched for this > work and I'll put a mesa/drm.git symlink in place to point to > libdrm.git. A number of people have already objected to these changes and have provided good reasons. Please just drop the issue. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'r6xx-r7xx-support' - 117 commits
On Sunday 29 March 2009 10:55:52 pm Alex Deucher wrote: > New commits: > commit c3c2ae466cfa1d4e079f6f0396e8f0f68ecb84b8 > Merge: 48b5f09... e2d7dfb... > Author: Alex Deucher > Date: Mon Mar 30 01:54:54 2009 -0400 > > Merge branch 'master' into r6xx-r7xx-support thank you -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: changes to upstreaming process for Linux code.
On Saturday 28 February 2009 05:28:38 am Pekka Paalanen wrote: > On Fri, 27 Feb 2009 23:54:21 -0800 > > vehemens wrote: > > On Friday 27 February 2009 01:45:50 pm Kristian Høgsberg wrote: > > > On Fri, Feb 27, 2009 at 4:40 PM, Dave Airlie wrote: > > > > Prompted by how well it worked with Intel, and changes in my personal > > > > life leading to reduced time availability (except at 4am...) I'm > > > > going to clarify the process for getting patches upstream now. > > > > (a...@amd also trialed this to get r600 upstream). > > > > > > > > 1. Apart from maybe minor changes I will no longer pull drm.git > > > > patches into Linux kernel tree automatically. > > > > > > > > 2. All patches should be sent to dri-devel and me against my drm-next > > > > tree. > > > > > > > > 3. Patches must conform to kernel coding standards and have > > > > acceptable checkpatch.pl results. My only major issues with > > > > checkpatch.pl is 80 char line length restrictions, please try your > > > > best but don't make the code really ugly to achieve this. Some > > > > scripts/people are too anal. This also means no kernel version checks > > > > upstream (however we might be able to convince people about this, if > > > > we get build from Linus tree working). > > > > > > > > 4. I will accept sub-module maintainers who want to maintain their > > > > driver in a git tree, but it'll take a bit of time for me to trust > > > > you that I'll pull directly, and patches should still pass by the > > > > list. Ask Eric how to do this. > > > > > > > > 5. if someone wants to step up and maintain drm.git as a going > > > > concern let me know, I'm glad to help if I can. > > > > > > Sounds good to me - one question: should we divorce libdrm from the > > > drm.git repo? > > > > As long as it stays on xorg, I wouldn't object as it would allow drm.git > > master to be used for leading edge development. > > Leading edge development of what, exactly? > If libdrm is moved out of drm.git, what is left is... Nouveau DRM? Poor wording on my part. What I (and others) would like see to happen is the various branches merged into master. Having everything centralized should improve the code quality as improvements would be pooled. > What does this suggestion of "divorce libdrm" mean? Only libdrm itself, > or all the libdrm_* additional libraries too? To a single other repo, > or each (sub-)library to its own repo? The intent here would be to remove any possible objection of merging the branches into master. If this is proves sucessful, the fork would die off at some point. > btw. where is Radeon DRM development happening now and in the near > future? Do you need drm.git linux-core for anything? Any development that occurs, doesn't show up in drm.git until someone decides to share it. How and when that occurs is up to the individual. The only solution I know of is to have a project that the developer wants to contribute to. Having multiple branches in one place would result in drm.git being much more useful then it currently is. This would include linux-core. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: changes to upstreaming process for Linux code.
On Saturday 28 February 2009 09:06:38 am Robert C. Noland III wrote: > On Fri, 2009-02-27 at 23:54 -0800, vehemens wrote: > > On Friday 27 February 2009 01:45:50 pm Kristian Høgsberg wrote: > > > On Fri, Feb 27, 2009 at 4:40 PM, Dave Airlie wrote: > > > > Prompted by how well it worked with Intel, and changes in my personal > > > > life leading to reduced time availability (except at 4am...) I'm > > > > going to clarify the process for getting patches upstream now. > > > > (a...@amd also trialed this to get r600 upstream). > > > > > > > > 1. Apart from maybe minor changes I will no longer pull drm.git > > > > patches into Linux kernel tree automatically. > > > > > > > > 2. All patches should be sent to dri-devel and me against my drm-next > > > > tree. > > > > > > > > 3. Patches must conform to kernel coding standards and have > > > > acceptable checkpatch.pl results. My only major issues with > > > > checkpatch.pl is 80 char line length restrictions, please try your > > > > best but don't make the code really ugly to achieve this. Some > > > > scripts/people are too anal. This also means no kernel version checks > > > > upstream (however we might be able to convince people about this, if > > > > we get build from Linus tree working). > > > > > > > > 4. I will accept sub-module maintainers who want to maintain their > > > > driver in a git tree, but it'll take a bit of time for me to trust > > > > you that I'll pull directly, and patches should still pass by the > > > > list. Ask Eric how to do this. > > > > > > > > 5. if someone wants to step up and maintain drm.git as a going > > > > concern let me know, I'm glad to help if I can. > > > > > > Sounds good to me - one question: should we divorce libdrm from the > > > drm.git repo? > > > > As long as it stays on xorg, I wouldn't object as it would allow drm.git > > master to be used for leading edge development. > > Not really, As long as people are allowed to bypass drm git and make > infrastructure changes, it means that in order for anyone else to try > and work in drm git, they have to do the work of back-porting other > peoples work before they can do their own work. There needs to be a > central point for drm development and that point is not Linus' tree. > > robert. People have always been free to bypass drm.git, and have been doing it for a number of years. The general consensus is to merge the different branches back into one place, that being drm.git. I don't see that happening while the "offical repository" of libdrm is in drm.git as there would always be objections to changes that weren't "main-stream". > > > cheers, > > > Kristian > > > > > > --- > > > --- Open Source Business Conference (OSBC), March 24-25, 2009, San > > > Francisco, CA -OSBC tackles the biggest issue in open source: Open > > > Sourcing the Enterprise -Strategies to boost innovation and cut costs > > > with open source participation -Receive a $600 discount off the > > > registration fee with the source code: SFAD > > > http://p.sf.net/sfu/XcvMzF8H > > > -- > > > ___ > > > Dri-devel mailing list > > > Dri-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > - > >- Open Source Business Conference (OSBC), March 24-25, 2009, San > > Francisco, CA -OSBC tackles the biggest issue in open source: Open > > Sourcing the Enterprise -Strategies to boost innovation and cut costs > > with open source participation -Receive a $600 discount off the > > registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H > > -- > > ___ > > Dri-devel mailing list > > Dri-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/dri-devel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: changes to upstreaming process for Linux code.
On Friday 27 February 2009 01:45:50 pm Kristian Høgsberg wrote: > On Fri, Feb 27, 2009 at 4:40 PM, Dave Airlie wrote: > > Prompted by how well it worked with Intel, and changes in my personal > > life leading to reduced time availability (except at 4am...) I'm going to > > clarify the process for getting patches upstream now. (a...@amd also > > trialed this to get r600 upstream). > > > > 1. Apart from maybe minor changes I will no longer pull drm.git patches > > into Linux kernel tree automatically. > > > > 2. All patches should be sent to dri-devel and me against my drm-next > > tree. > > > > 3. Patches must conform to kernel coding standards and have acceptable > > checkpatch.pl results. My only major issues with checkpatch.pl is 80 char > > line length restrictions, please try your best but don't make the code > > really ugly to achieve this. Some scripts/people are too anal. This also > > means no kernel version checks upstream (however we might be able to > > convince people about this, if we get build from Linus tree working). > > > > 4. I will accept sub-module maintainers who want to maintain their driver > > in a git tree, but it'll take a bit of time for me to trust you that I'll > > pull directly, and patches should still pass by the list. Ask Eric how to > > do this. > > > > 5. if someone wants to step up and maintain drm.git as a going concern > > let me know, I'm glad to help if I can. > > Sounds good to me - one question: should we divorce libdrm from the > drm.git repo? As long as it stays on xorg, I wouldn't object as it would allow drm.git master to be used for leading edge development. > cheers, > Kristian > > --- >--- Open Source Business Conference (OSBC), March 24-25, 2009, San > Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing > the Enterprise -Strategies to boost innovation and cut costs with open > source participation -Receive a $600 discount off the registration fee with > the source code: SFAD http://p.sf.net/sfu/XcvMzF8H > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: changes to upstreaming process for Linux code.
On Friday 27 February 2009 01:40:25 pm Dave Airlie wrote: > Prompted by how well it worked with Intel, and changes in my personal life > leading to reduced time availability (except at 4am...) I'm going to > clarify the process for getting patches upstream now. (a...@amd also > trialed this to get r600 upstream). > > 1. Apart from maybe minor changes I will no longer pull drm.git patches > into Linux kernel tree automatically. > > 2. All patches should be sent to dri-devel and me against my drm-next > tree. > > 3. Patches must conform to kernel coding standards and have acceptable > checkpatch.pl results. My only major issues with checkpatch.pl is 80 char > line length restrictions, please try your best but don't make the code > really ugly to achieve this. Some scripts/people are too anal. This also > means no kernel version checks upstream (however we might be able to > convince people about this, if we get build from Linus tree working). > > 4. I will accept sub-module maintainers who want to maintain their driver > in a git tree, but it'll take a bit of time for me to trust you that I'll > pull directly, and patches should still pass by the list. Ask Eric how to > do this. > > 5. if someone wants to step up and maintain drm.git as a going concern let > me know, I'm glad to help if I can. I would be interested, but I have been unable to get a commit bit for 6 months. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] Remove Intel drivers from linux-core
On Tuesday 17 February 2009 05:43:32 pm Robert C. Noland III wrote: > On Mon, 2009-02-16 at 18:39 +, Owain Ainsworth wrote: > > On Sat, Feb 14, 2009 at 11:24:18PM +0200, Pekka Paalanen wrote: > > > >From 29d3f6e9c1258736c3199834b293b8128faef2ad Mon Sep 17 00:00:00 2001 > > > > > > From: Pekka Paalanen > > > Date: Sat, 14 Feb 2009 21:49:08 +0200 > > > Subject: [PATCH] Remove Intel drivers from linux-core > > > > > > Both i810 and i915 DRM Linux kernel specific sources are removed. > > > > > > Intel developers have stated, that their DRM development continues > > > elsewhere in some Linux kernel trees. This makes the code in drm.git > > > just dead weight. This removal allows further cleanup of compatibility > > > code. > > > > > > shared-core and bsd-core are left untouched. > > > > Personally i'd also kill bsd-core, since it's outdates and contains so > > much shit we don't want. > > > > Then again Robert may have something to say bout this. > > I still have code against it... I'm not sure what I'm going to do about > it though How about incorporating my patches while I continue to attempt to obtain a commit account:? >robert. > >> -0- -- who is still slacking on getting a fd.o account. >-- >Robert C. Noland III >2 Hip Networks -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Thursday 11 December 2008 04:28:48 pm Jesse Barnes wrote: > On Thursday, December 11, 2008 4:16 pm vehemens wrote: > > On Wednesday 10 December 2008 03:52:08 pm Jesse Barnes wrote: > > >... > > >New commits: > > >commit 9583c099b4a08b49e03f7b461c344b6d277fd262 > > >Author: Jesse Barnes > > >Date: Wed Dec 10 15:47:28 2008 -0800 > > > > > >Revert "Merge branch 'modesetting-gem'" > > > > > >This reverts commit 6656db10551bbb8770dd945b6d81d5138521f208. > > > > > >We really just want the libdrm and ioctl bits, not all the driver > > >stuff. > > >... > > > > Could you help me out and explain why we don't want the merge? > > Because it pulled in a bunch of driver code that probably isn't ready (at > least I didn't want to merge it w/o acks from Dave, Jerome and Stephane). > I just posted a more minimal patch earlier today. I can understand not merging code when it's not ready, but that begs the question on who would be affected at this point given the way most distributions are handled :? -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Wednesday 10 December 2008 03:52:08 pm Jesse Barnes wrote: >... >New commits: >commit 9583c099b4a08b49e03f7b461c344b6d277fd262 >Author: Jesse Barnes >Date: Wed Dec 10 15:47:28 2008 -0800 > >Revert "Merge branch 'modesetting-gem'" > >This reverts commit 6656db10551bbb8770dd945b6d81d5138521f208. > >We really just want the libdrm and ioctl bits, not all the driver >stuff. >... Could you help me out and explain why we don't want the merge? -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
drm vblank memory allocation
Would anyone object to using a struct for the vblank crtc data to eliminate
the multiple allocs / frees?
For example:
struct drm_vblank {
wait_queue_head_t vbl_queue;
atomic_t _vblank_count;
struct drm_vbl_sig_list vbl_sigs;
atomic_t vblank_refcount;
u32 last_vblank;
int vblank_enabled;
u32 vblank_premodeset;
u32 vblank_suspend;
};
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: misc drm patches
On Wednesday 28 May 2008 04:35:42 am Oleg Nauman wrote: > On Wed, May 28, 2008 at 10:34 AM, vehemens <[EMAIL PROTECTED]> wrote: > > Here are a few drm patches. > > > > correct another lock leak. > > > > add missing link. > > > > negate return value. minor cleanup while we are here. > > It just panics my laptop (think due to another bug discovered): > > Unread portion of the kernel message buffer: > info: [drm] Setting GART location based on new memory map > bus_dmamem_alloc failed to align memory properly. I was seeing some instability before my patch, mainly xserver, sometimes kernel. Being that xorg is such a moving target (and this isn't my day job), I haven't spent the time to track it down. My machine is freebsd 7.0 stable from about 4/15/08, and pretty much pre mpx xorg running on a AMD64X2 and RV370. I also run compiz 7.4. What are you running? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
misc drm patches
Here are a few drm patches.
correct another lock leak.
add missing link.
negate return value. minor cleanup while we are here.
diff --git a/bsd-core/drm_bufs.c b/bsd-core/drm_bufs.c
index 3508331..c793634 100644
--- a/bsd-core/drm_bufs.c
+++ b/bsd-core/drm_bufs.c
@@ -832,12 +832,12 @@ int drm_addbufs_sg(struct drm_device *dev, drm_buf_desc_t *request)
if (request->count < 0 || request->count > 4096)
return EINVAL;
- DRM_SPINLOCK(&dev->dma_lock);
-
order = drm_order(request->size);
if (order < DRM_MIN_ORDER || order > DRM_MAX_ORDER)
return EINVAL;
+ DRM_SPINLOCK(&dev->dma_lock);
+
/* No more allocations after first buffer-using ioctl. */
if (dev->buf_use != 0) {
DRM_SPINUNLOCK(&dev->dma_lock);
diff --git a/bsd-core/radeon_microcode.h b/bsd-core/radeon_microcode.h
new file mode 12
index 000..709fff3
--- /dev/null
+++ b/bsd-core/radeon_microcode.h
@@ -0,0 +1 @@
+../shared-core/radeon_microcode.h
\ No newline at end of file
diff --git a/shared-core/radeon_irq.c b/shared-core/radeon_irq.c
index d21761f..0844c0b 100644
--- a/shared-core/radeon_irq.c
+++ b/shared-core/radeon_irq.c
@@ -74,7 +74,7 @@ int radeon_enable_vblank(struct drm_device *dev, int crtc)
default:
DRM_ERROR("tried to enable vblank on non-existent crtc %d\n",
crtc);
- return EINVAL;
+ return -EINVAL;
}
} else {
switch (crtc) {
@@ -87,7 +87,7 @@ int radeon_enable_vblank(struct drm_device *dev, int crtc)
default:
DRM_ERROR("tried to enable vblank on non-existent crtc %d\n",
crtc);
- return EINVAL;
+ return -EINVAL;
}
}
@@ -279,9 +279,8 @@ u32 radeon_get_vblank_counter(struct drm_device *dev, int crtc)
} else if (crtc == 1) {
crtc_cnt_reg = RADEON_CRTC2_CRNT_FRAME;
crtc_status_reg = RADEON_CRTC2_STATUS;
- } else {
+ } else
return -EINVAL;
- }
return RADEON_READ(crtc_cnt_reg) + (RADEON_READ(crtc_status_reg) & 1);
}
}
@@ -372,9 +371,9 @@ void radeon_driver_irq_uninstall(struct drm_device * dev)
dev_priv->irq_enabled = 0;
+ /* Disable *all* interrupts */
if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS690)
RADEON_WRITE(R500_DxMODE_INT_MASK, 0);
- /* Disable *all* interrupts */
RADEON_WRITE(RADEON_GEN_INT_CNTL, 0);
}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: BSD libdrm
On Thursday 01 May 2008 07:16:36 am Jerome Glisse wrote: > On Tue, 29 Apr 2008 20:51:45 -0700 > > vehemens <[EMAIL PROTECTED]> wrote: > > The primary goal is to update the BSD drm code with the recent linux > > changes including linux drm memory management code. I haven't seen > > anything in the code that would prevent this from occurring, but I'm new > > at this. > > I don't know how close you are to BSD kernel people but i guess they > are the one to know best what they want. I think linux will slowly > (timeframe being a year or little bit more) move to kernel modesetting. > So the question is does BSD folks like this idea or not, there is > many security implication in this and getting it right is not trivial. > So maybe ask the BSD kernel community on their feeling about drm > and drm+memory manager+modesetting. I'll drop them a line, and see what suggestions they have. As a user, I would like to see most of the linux DRM features incorporated, > If they like it, i suggest porting memory manager first, then modesetting > (you need memory manager for modesetting at least i strongly discourage > to do it without one). Currently I'm merging the core code which results in mostly using the linux code with some macros and ifdefs. There are a few things I plan to keep from the freebsd side however. Once I get the baseline merged, I will begin work on the memory manager. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: BSD libdrm
On Tuesday 29 April 2008 08:35:36 am Jerome Glisse wrote: > On Mon, 28 Apr 2008 08:26:41 -0700 > > vehemens <[EMAIL PROTECTED]> wrote: > > I'm currently working on updating the bsd libdrm for use with my freebsd > > system. To reduce the work involved, I'm using some code from the linux > > kernel for lists and locks. This also greatly reduces the amount of > > unique code required. > > > > Unfortunately I only have radeon rv370 and intel i810 class hardware so > > my testing capability is somewhat limited. > > > > My thoughts are that i9i5 flavor hardware may be the best way to to check > > out the code. Another option is to stick with radeon and to switch over > > to the mode-setting branch at some point. > > > > So does anyone have any ideas on what would be the best testing approach? > > What are your aims ? As far as i know BSD/drm does not have memory > manager support thus modesetting is not operational on BSD as it needs > the memory manager. libdrm so far is a pretty small layer on top of > kernel interface to make userspace life easier. For testing current > BSD functionalities i believe a working 3D acceleration under X is > the best use case given that DRM is primilary designed and written > for this usage. The primary goal is to update the BSD drm code with the recent linux changes including linux drm memory management code. I haven't seen anything in the code that would prevent this from occurring, but I'm new at this. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
BSD libdrm Update
I'm currently working on updating the bsd libdrm for use with my freebsd system. To reduce the work involved, I'm using some code from the linux kernel for lists and atomics. This also greatly reduces the amount of unique code required. Unfortunately I only have radeon rv370 and intel i810 class hardware so my testing capability is somewhat limited. My thoughts are that i9i5 flavor hardware may be the best way to to check out the code. Another option is to stick with radeon and to switch over to the mode-setting branch at some point. So does anyone have any ideas on what would be the best testing approach? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
BSD libdrm
I'm currently working on updating the bsd libdrm for use with my freebsd system. To reduce the work involved, I'm using some code from the linux kernel for lists and locks. This also greatly reduces the amount of unique code required. Unfortunately I only have radeon rv370 and intel i810 class hardware so my testing capability is somewhat limited. My thoughts are that i9i5 flavor hardware may be the best way to to check out the code. Another option is to stick with radeon and to switch over to the mode-setting branch at some point. So does anyone have any ideas on what would be the best testing approach? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM_ERR Removal
On Monday 23 July 2007 07:59:24 am Eric Anholt wrote:
> This was used to make all ioctl handlers return -errno on linux and
> errno on *BSD. Instead, just return -errno in shared code, and flip sign
> on return from shared code to *BSD code.
I was trying to determine why my system hung and focused on the shared code
change. Then I decide it was time to forage for food after looking at the
commit diff.
There are a couple of problems with the BSD driver however.
1) Locking is broken in drm_auth.c causing my system to hang. Patch is at the
end of this email. I pasted it in as well as attaching it as I have had
problems on other mailing lists with attachments.
2) In drm_getstats, memset(&stats, 0, sizeof(stats)) should be
memset(stats, 0, sizeof(drm_stats_t)). Could also of used bzero.
3) In drm_setversion, retv is never used. I changed the routine to work as
before, but havn't yet read the drm specification on what should occur or
looked at the rest of the code to see if it matters.
--- bsd-core/drm_auth.c.orig2007-07-21 23:13:43.0 -0700
+++ bsd-core/drm_auth.c 2007-07-25 01:43:08.0 -0700
@@ -1,4 +1,4 @@
-/* drm_auth.h -- IOCTLs for authentication -*- linux-c -*-
+/* drm_auth.c -- IOCTLs for authentication -*- linux-c -*-
* Created: Tue Feb 2 08:37:54 1999 by [EMAIL PROTECTED]
*/
/*-
@@ -66,7 +66,6 @@
entry->priv = priv;
entry->next = NULL;
- DRM_LOCK();
if (dev->magiclist[hash].tail) {
dev->magiclist[hash].tail->next = entry;
dev->magiclist[hash].tail = entry;
@@ -74,7 +73,6 @@
dev->magiclist[hash].head = entry;
dev->magiclist[hash].tail = entry;
}
- DRM_UNLOCK();
return 0;
}
@@ -88,7 +86,6 @@
DRM_DEBUG("%d\n", magic);
hash = drm_hash_magic(magic);
- DRM_LOCK();
for (pt = dev->magiclist[hash].head; pt; prev = pt, pt = pt->next) {
if (pt->magic == magic) {
if (dev->magiclist[hash].head == pt) {
@@ -100,11 +97,9 @@
if (prev) {
prev->next = pt->next;
}
- DRM_UNLOCK();
return 0;
}
}
- DRM_UNLOCK();
free(pt, M_DRM);
return EINVAL;
@@ -129,8 +124,8 @@
continue;
} while (drm_find_file(dev, auth->magic));
file_priv->magic = auth->magic;
- DRM_UNLOCK();
drm_add_magic(dev, file_priv, auth->magic);
+ DRM_UNLOCK();
}
DRM_DEBUG("%u\n", auth->magic);
@@ -152,8 +147,8 @@
drm_remove_magic(dev, auth->magic);
DRM_UNLOCK();
return 0;
- } else {
- DRM_UNLOCK();
- return EINVAL;
}
+
+ DRM_UNLOCK();
+ return EINVAL;
}
--- bsd-core/drm_auth.c.orig 2007-07-21 23:13:43.0 -0700
+++ bsd-core/drm_auth.c 2007-07-25 01:43:08.0 -0700
@@ -1,4 +1,4 @@
-/* drm_auth.h -- IOCTLs for authentication -*- linux-c -*-
+/* drm_auth.c -- IOCTLs for authentication -*- linux-c -*-
* Created: Tue Feb 2 08:37:54 1999 by [EMAIL PROTECTED]
*/
/*-
@@ -66,7 +66,6 @@
entry->priv = priv;
entry->next = NULL;
- DRM_LOCK();
if (dev->magiclist[hash].tail) {
dev->magiclist[hash].tail->next = entry;
dev->magiclist[hash].tail = entry;
@@ -74,7 +73,6 @@
dev->magiclist[hash].head = entry;
dev->magiclist[hash].tail = entry;
}
- DRM_UNLOCK();
return 0;
}
@@ -88,7 +86,6 @@
DRM_DEBUG("%d\n", magic);
hash = drm_hash_magic(magic);
- DRM_LOCK();
for (pt = dev->magiclist[hash].head; pt; prev = pt, pt = pt->next) {
if (pt->magic == magic) {
if (dev->magiclist[hash].head == pt) {
@@ -100,11 +97,9 @@
if (prev) {
prev->next = pt->next;
}
- DRM_UNLOCK();
return 0;
}
}
- DRM_UNLOCK();
free(pt, M_DRM);
return EINVAL;
@@ -129,8 +124,8 @@
continue;
} while (drm_find_file(dev, auth->magic));
file_priv->magic = auth->magic;
- DRM_UNLOCK();
drm_add_magic(dev, file_priv, auth->magic);
+ DRM_UNLOCK();
}
DRM_DEBUG("%u\n", auth->magic);
@@ -152,8 +147,8 @@
drm_remove_magic(dev, auth->magic);
DRM_UNLOCK();
return 0;
- } else {
- DRM_UNLOCK();
- return EINVAL;
}
+
+ DRM_UNLOCK();
+ return EINVAL;
}
-
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
DRM_ERR Removal
Isn't DRM_ERR() required for compatibility? - 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
RADEON/AIGLX DRI Lock At Initialization
On Monday 09 July 2007 02:51:37 am Michel Dänzer wrote: > On Mon, 2007-07-09 at 00:38 -0700, vehemens wrote: > > I believe I have narrowed the problem down to __glXDRIscreenProbe() > > removing the RADEON DRM lock that was set up with DRIFinishScreenInit(). > > > > What happens is that __glXDRIscreenProbe() calls drmOpenOnce() which uses > > drmAvailable() to test for the presence of the kernel driver. If the > > test passes, it closes the file descriptor and removes the lock. > > drmAvailable() opens and closes its own DRM file desriptor, which > shouldn't have such side effects on existing DRM file descriptors. Could > there be a bug in the DRM BSD code? Does the same problem occur on Linux > for you? I've never seen it, FWIW. I was told that I should address this problem here. I'm running freebsd and xorg current. Is there a document that lists which descriptors are used by a particular component? - 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: r500 - where to start?
On Saturday 23 December 2006 14:23, Jerome Glisse wrote: > On 12/23/06, Magnus Ahlberg <[EMAIL PROTECTED]> wrote: > > I know that there has been some discussion about the r500 chip and how > > tough it will be to create a working driver for it. However, I for one > > would love to see an open alternative to the fglrx and I want to know, > > where to start? I own a laptop with a X1600 mobility radeon card. > I am myself planning to take a look into that matter in the > few coming days. Maybe i will got somethings in couple of > day. I started looking at the xorg ati driver as well. Here are a few of my ideas/comments: Need to work the current driver to bypass pre 520 mode and 3d. Not sure about 2d. Finding and using the mode registers don't seem to be a big problem. Just need to do it. The I2C interface has been replaced with a byte based state machine (i.e. no more bit banging). - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM/Mesa Patches
Posting my latest DRM and Mesa patches in case they should prove useful to
anyone else. They are to head as of early Saturday.
I moved the CP idle outside the while loop in radeon_state.c. I think it may
apply to the R300 as well as there is an "if R300 idle command" in the
Xserver RADEONEnterServer function.
I have not tried removing the DRM changes since adding the Mesa change. Just
sticking with something that doesn't lockup.
diff -ru drm120205/shared-core/radeon_state.c
drmbld/shared-core/radeon_state.c
--- drm120205/shared-core/radeon_state.cMon Nov 28 22:05:43 2005
+++ drmbld/shared-core/radeon_state.c Sat Dec 3 13:00:57 2005
@@ -2388,7 +2388,7 @@
*/
BEGIN_RING(2);
- RADEON_WAIT_UNTIL_3D_IDLE();
+ RADEON_WAIT_UNTIL_IDLE();
ADVANCE_RING();
@@ -2737,6 +2737,7 @@
drm_radeon_cmd_header_t header;
int orig_nbox, orig_bufsz;
char *kbuf = NULL;
+ RING_LOCALS;
LOCK_TEST_WITH_RETURN(dev, filp);
@@ -2775,7 +2776,17 @@
}
orig_nbox = cmdbuf.nbox;
-
+
+ /* Wait for the engine to idle before the indirect buffer
+* is processed.
+*/
+
+ BEGIN_RING(2);
+
+ RADEON_WAIT_UNTIL_IDLE();
+
+ ADVANCE_RING();
+
if(dev_priv->microcode_version == UCODE_R300) {
int temp;
temp=r300_do_cp_cmdbuf(dev, filp, filp_priv, &cmdbuf);
@@ -2785,7 +2796,7 @@
return temp;
}
-
+
/* microcode_version != r300 */
while (cmdbuf.bufsz >= sizeof(header)) {
header.i = *(int *)cmdbuf.buf;
diff -ru mesa120205/Mesa/src/mesa/drivers/dri/r200/r200_state_init.c
xorgcursrc/xc/extras/Mesa/src/mesa/drivers/dri/r200/r200_state_init.c
--- mesa120205/Mesa/src/mesa/drivers/dri/r200/r200_state_init.c Fri Dec 2
00:56:29 2005
+++ xorgcursrc/xc/extras/Mesa/src/mesa/drivers/dri/r200/r200_state_init.c
Sat Dec 3 12:09:32 2005
@@ -253,8 +253,8 @@
ALLOC_STATE( zbs, always, ZBS_STATE_SIZE, "ZBS/zbias", 0 );
ALLOC_STATE( tf, tf, TF_STATE_SIZE, "TF/tfactor", 0 );
if (rmesa->r200Screen->drmSupportsFragShader) {
- if (rmesa->r200Screen->chip_family == CHIP_FAMILY_R200) {
- /* make sure texture units 0/1 are emitted pair-wise for r200 t0 hang
workaround */
+ if (rmesa->r200Screen->chip_flags & R200_CHIPSET_TEX01_BROKEN) {
+ /* make sure texture units 0/1 are emitted pair-wise for t0 hang
workaround */
ALLOC_STATE( tex[0], tex_pair, TEX_STATE_SIZE_NEWDRM, "TEX/tex-0",
0 );
ALLOC_STATE( tex[1], tex_pair, TEX_STATE_SIZE_NEWDRM, "TEX/tex-1",
1 );
ALLOC_STATE( tam, tex_any, TAM_STATE_SIZE, "TAM/tam", 0 );
@@ -273,7 +273,7 @@
ALLOC_STATE( afs[1], afs, AFS_STATE_SIZE, "AFS/afsinst-1", 1 );
}
else {
- if (rmesa->r200Screen->chip_family == CHIP_FAMILY_R200) {
+ if (rmesa->r200Screen->chip_flags & R200_CHIPSET_TEX01_BROKEN) {
ALLOC_STATE( tex[0], tex_pair, TEX_STATE_SIZE_OLDDRM, "TEX/tex-0",
0 );
ALLOC_STATE( tex[1], tex_pair, TEX_STATE_SIZE_OLDDRM, "TEX/tex-1",
1 );
ALLOC_STATE( tam, tex_any, TAM_STATE_SIZE, "TAM/tam", 0 );
diff -ru mesa120205/Mesa/src/mesa/drivers/dri/r200/r200_texstate.c
xorgcursrc/xc/extras/Mesa/src/mesa/drivers/dri/r200/r200_texstate.c
--- mesa120205/Mesa/src/mesa/drivers/dri/r200/r200_texstate.c Fri Dec 2
00:56:29 2005
+++ xorgcursrc/xc/extras/Mesa/src/mesa/drivers/dri/r200/r200_texstate.c Sat
Dec 3 12:13:52 2005
@@ -1678,11 +1678,10 @@
r200ChooseVertexState( ctx );
- if (rmesa->r200Screen->chip_family == CHIP_FAMILY_R200) {
+ if (rmesa->r200Screen->chip_flags & R200_CHIPSET_TEX01_BROKEN) {
/*
- * T0 hang workaround -
- * not needed for r200 derivatives
+ * T0 hang workaround
*/
if ((rmesa->hw.ctx.cmd[CTX_PP_CNTL] & R200_TEX_ENABLE_MASK) ==
R200_TEX_0_ENABLE &&
(rmesa->hw.tex[0].cmd[TEX_PP_TXFILTER] & R200_MIN_FILTER_MASK) >
R200_MIN_FILTER_LINEAR) {
diff -ru mesa120205/Mesa/src/mesa/drivers/dri/radeon/radeon_chipset.h
xorgcursrc/xc/extras/Mesa/src/mesa/drivers/dri/radeon/radeon_chipset.h
--- mesa120205/Mesa/src/mesa/drivers/dri/radeon/radeon_chipset.hFri
Dec 2 21:21:24 2005
+++ xorgcursrc/xc/extras/Mesa/src/mesa/drivers/dri/radeon/radeon_chipset.h
Sat Dec 3 19:47:56 2005
@@ -133,5 +133,6 @@
#define RADEON_CHIPSET_TCL (1 << 2)/* tcl support - any
radeon */
#define RADEON_CHIPSET_BROKEN_STENCIL (1 << 3)/* r100 stencil bug */
#define R200_CHIPSET_YCBCR_BROKEN (1 << 4)/* r200 ycbcr bug */
+#define R200_CHIPSET_TEX01_BROKEN (1 << 5)/* r200 texture pair
bug */
#endif /* _RADEON_CHIPSET_H */
diff -ru mesa120205/Mesa/src/mesa/drivers/dri/radeon/radeon_screen.c
xorgcursrc/xc/extras/Mesa/src/mesa/drivers/dri/radeon/radeon_screen.c
--- mesa120205/Mesa/src/mesa/drivers/dri/radeon/radeon_screen.c Fri Dec 2
21:21:24 2005
+++ xorgcurs
Re: RADEON Scratch Register Usage
On Monday 28 November 2005 02:55 pm, Benjamin Herrenschmidt wrote: > The DRM lock should protect that ... note that I just spotted a DRM fix > "drm: fix quiescent locking" going into the linux kernel that may > explain races with the DRM lock. > > Also, there has been historical issues with the scratch register > writeback. Have you tried disabling writeback via AGP ? I'm using FreeBSD 6.0 so it's unlikely that it's a kernel locking problem, at least not the same one. I did find what appears to be a single client Mesa problem which I now have a workaround for. I'll try running multiple client again this week or next. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RADEON Scratch Register Usage
On Monday 28 November 2005 02:55 pm, Benjamin Herrenschmidt wrote: > On Mon, 2005-11-28 at 02:18 -0800, vehemens wrote: > > I've been looking at my remaining lockups, and find that I keep coming > > back to the use of scratch registers in the driver for one of them. > > > > If I'm reading the code correctly, the scratch registers are per device, > > not per client. This would mean that you can't run more then one client > > without the potential of one stepping on the other. > > > > My read of the MESA code suggests that a stepped on client could then > > stall out waiting for a condition that would probably never happen > > (non-deterministic anyway). > > > > Does this sound correct, or am I missing something? > > The DRM lock should protect that ... note that I just spotted a DRM fix > "drm: fix quiescent locking" going into the linux kernel that may > explain races with the DRM lock. > > Also, there has been historical issues with the scratch register > writeback. Have you tried disabling writeback via AGP ? > > Ben. Thanks for the pointers. It helped. What I did find is that I have random lockups during texture updates, and that it's easy to trigger. Still looking into the root cause. Noticed that the surface ioctl's do not have locking yet touch the ring via radeon_apply_surface_regs. Didn't seem to be a problem in my case. Don't all ioctl's that touch the ring need to be locked?? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RADEON Scratch Register Usage
I've been looking at my remaining lockups, and find that I keep coming back to the use of scratch registers in the driver for one of them. If I'm reading the code correctly, the scratch registers are per device, not per client. This would mean that you can't run more then one client without the potential of one stepping on the other. My read of the MESA code suggests that a stepped on client could then stall out waiting for a condition that would probably never happen (non-deterministic anyway). Does this sound correct, or am I missing something? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon RV250 Lockup
It took over an hour this time, but it locked up while running three different
demos.
> Looks good.. but dude diff -u plz
>
> I can't read context diffs to save my life...
>
> Dave.
Done.
drmbld/shared-core/radeon_state.c
--- drm111605/shared-core/radeon_state.cFri Nov 11 20:25:43 2005
+++ drmbld/shared-core/radeon_state.c Wed Nov 23 22:15:17 2005
@@ -2388,7 +2388,7 @@
*/
BEGIN_RING(2);
- RADEON_WAIT_UNTIL_3D_IDLE();
+ RADEON_WAIT_UNTIL_IDLE();
ADVANCE_RING();
@@ -2737,6 +2737,7 @@
drm_radeon_cmd_header_t header;
int orig_nbox, orig_bufsz;
char *kbuf = NULL;
+ RING_LOCALS;
LOCK_TEST_WITH_RETURN(dev, filp);
@@ -2791,6 +2792,11 @@
header.i = *(int *)cmdbuf.buf;
cmdbuf.buf += sizeof(header);
cmdbuf.bufsz -= sizeof(header);
+
+ /* hack */
+ BEGIN_RING(2);
+ RADEON_WAIT_UNTIL_IDLE();
+ ADVANCE_RING();
switch (header.header.cmd_type) {
case RADEON_CMD_PACKET:
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon RV250 Lockup
I appear to of eliminated my remaining lockups by also idling the 2D engine in
radeon_cp_indirect which is being called from the xserver. Here is my latest
patch.
*** drm111605/shared-core/radeon_state.cFri Nov 11 20:25:43 2005
--- drmbld/shared-core/radeon_state.c Wed Nov 23 22:15:17 2005
***
*** 2388,2394
*/
BEGIN_RING(2);
! RADEON_WAIT_UNTIL_3D_IDLE();
ADVANCE_RING();
--- 2388,2394
*/
BEGIN_RING(2);
! RADEON_WAIT_UNTIL_IDLE();
ADVANCE_RING();
***
*** 2737,2742
--- 2737,2743
drm_radeon_cmd_header_t header;
int orig_nbox, orig_bufsz;
char *kbuf = NULL;
+ RING_LOCALS;
LOCK_TEST_WITH_RETURN(dev, filp);
***
*** 2791,2796
--- 2792,2802
header.i = *(int *)cmdbuf.buf;
cmdbuf.buf += sizeof(header);
cmdbuf.bufsz -= sizeof(header);
+
+ /* hack */
+ BEGIN_RING(2);
+ RADEON_WAIT_UNTIL_IDLE();
+ ADVANCE_RING();
switch (header.header.cmd_type) {
case RADEON_CMD_PACKET:
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Radeon RV250 Lockup
I've managed to eliminate a number of lockups when running one or more copies
of glxgears and other GL programs with the patch below.
This suggests that the driver needs some type of command timing/processing
rules to prevent lockup (NOPs?).
I working on the other lockups, but debug seems to fix the problem which is
another indicator that the remaining problems are due to timing.
*** drm111605/shared-core/radeon_state.cFri Nov 11 20:25:43 2005
--- drmbld/shared-core/radeon_state.c Wed Nov 23 11:35:29 2005
***
*** 2737,2742
--- 2737,2743
drm_radeon_cmd_header_t header;
int orig_nbox, orig_bufsz;
char *kbuf = NULL;
+ RING_LOCALS;
LOCK_TEST_WITH_RETURN(dev, filp);
***
*** 2791,2796
--- 2792,2802
header.i = *(int *)cmdbuf.buf;
cmdbuf.buf += sizeof(header);
cmdbuf.bufsz -= sizeof(header);
+
+ /* hack */
+ BEGIN_RING(2);
+ RADEON_WAIT_UNTIL_IDLE();
+ ADVANCE_RING();
switch (header.header.cmd_type) {
case RADEON_CMD_PACKET:
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
