Re: [Mesa-dev] Experimental branch.
On Sun, 4 Jul 1999, Keith Whitwell wrote: > > And another question, when will Mesa switch to Glide3, might it happen > > before 3.1 release? > > Daryll seems to have a fair bit on his plate - and he's never put any sort of > date on a glide 3 release. The last time I talked to Daryll about this (about a month ago IIRC), he said it wasn't a big deal to do it but that he wasn't giving it priority since Mesa didn't use it yet. Since Mesa doesn't use it because it isn't present for Linux yet, we have a bit of a chicken-and-egg situation. I guess it needs someone to compile Mesa under Windoze using GLIDE 3... Steve Baker(817)619-2657 (Vox/Vox-Mail) Raytheon Systems Inc. (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Experimental branch.
Miklós Fazekas wrote: > > Hello! > > When will Keith new optimalizations be merged from the Experimental branch? > Will it be the last biggest change before the 3.1 release? I'll be starting on it tomorrow. Its the last big change from me for 3.1 - and I don't know of any other ones floating around out there. > Is there anyone working on the bugs in it? If so on what's bugs? > In some circumstances it's sending "inf" values to the Voodoo, is it a known > bug, or is it only found on MacOS? I don't think many people have tried it for stuff beyond q3 - therefore I'm sure there are bugs. I know of a couple, but 'inf' is a new one for me - details please... > Is it the latest snapshot of Keiths development? Pretty much - I took a little break to work on some g200 stuff, and then last week to go & talk to PI about work. Merging that stuff back into the main branch is my priority for the next couple of days. > And another question, when will Mesa switch to Glide3, might it happen > before 3.1 release? Daryll seems to have a fair bit on his plate - and he's never put any sort of date on a glide 3 release. Keith ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] experimental branch
Keith Whitwell wrote: > > Brian Paul wrote: > > > > Keith, I'd like to hear what your longer-term coding plans are. Do > > you see a milestone in your work for a 3.1 release? > > I think you could say that the latest batch of changes pretty much > represents the end of a certain line of improvements. I know Holger is > doing some 3dnow assembly in support of those changes, and there is > other tweaking possible. Apart from those issues I'm happy to draw a > line under what's been done so far and call it a unit. > > My next change to the Mesa core will probably be to provide some support > for floating point colors if that is what we're getting from the API. > I'm also interested in trying to clean up the way we handle vertex > copying at the end of an immediate vb, opening up the fast path to the > immediate pipeline, and fixing some other immediate mode issues of my > own making. I don't think these changes are worth delaying a release > for. > > So I think I've done my last major chunk of coding for this release - > just clean-up, bugfixes and everybody else's work to go... OK, great. Here's what's left, off the top of my head: - conformance testing (I'll try to get back to this ASAP) - 3Dfx driver bugs? (Joe Water's fog bug, for example) - Windows driver bugs (Wilmot Theierry's list of May 28) - put src-glut/ into CVS - is Windows support still in need of tweaking? - multi-byte font bug in GLX - library naming issue: libMesaGL.so vs libGL.so (probably should switch to the later for 3.1) - should GL_SGIS_multitexture be removed? I say yes. - configure-based building? Wait and see, I think. Any additions? -Brian -- Brian PaulAvid Technology / Softimage [EMAIL PROTECTED] ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] experimental branch
Stephen J Baker wrote: > Perhaps it's time for Mesa to go to the dual-stream approach of the > Linux Kernel and other packages like The GIMP where odd numbered > releases are where new code goes and even numbered get all the bug > fixes. > ... > What does everyone else think about this idea? I'll have to think about it for a while but my first instinct is to stick with the current system. That is, release a series of betas which initially introduce new optimizations and features and progress toward bug-fix betas. After I've released a beta which gets few or no bug reports I'll typically rename that beta as a final release. I believe there are enough people grabbing the betas to exercise it acceptably. This has worked reasonably well so far. There are always bug fixes for the last official release (ala patches_to_3.0/ on the ftp site) but they're seldom serious or widely experienced by users. I don't relish the thought of fixing bugs in two branches. The time between the 3.0 and 3.1 releases is going to be much longer than normal. That's because there's been a tremendous amount of new work. I'd like to see smaller, more frequent releases after 3.1. -Brian -- Brian PaulAvid Technology / Softimage [EMAIL PROTECTED] ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] experimental branch
Stephen J Baker wrote: > > > One SPECIFIC reason to go this way is that it gives people > writing low level drivers a stable (even numbered) platform > to work with. > > What does everyone else think about this idea? OK, but really that's what having a development and stable branch in cvs acheives. Then you can number snapshots from each branch however you like - the odd/even way being one that springs to mind, but then again developers should be using cvs, so you don't need odd numbers... Keith ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] experimental branch
On Tue, 8 Jun 1999, Brian Paul wrote: > > The real question is whether Brian wants the next release version to > > include the new code or not. > > I don't have a date in mind for the next beta release. > > I'd like to keep the mainline code pretty much stable. After Keith > has tested and debugged his code branch with most of the demo/sample > programs, Quake, etc. then merging into the mainline is appropriate. > > In other words, when people download and test the latest CVS snapshot > I'd like them to see forward progress (fewer bugs, better speed) > rather than find newly broken code. > > I was planning on doing more conformance testing/fixing pretty soon. > I'd rather do that with stable, mainline code. > > Keith, I'd like to hear what your longer-term coding plans are. Do > you see a milestone in your work for a 3.1 release? Perhaps it's time for Mesa to go to the dual-stream approach of the Linux Kernel and other packages like The GIMP where odd numbered releases are where new code goes and even numbered get all the bug fixes. In this case, that would mean finding a reasonably usable 3.1 and releasing it as 3.2.0 - with the expectation that we'd have to fix bugs in it to make progressively more stable 3.2.1, 3.2.2, etc. Meanwhile (and pretty much simultaneous with the release of 3.2.0 would come 3.3.0 which would be where all the major new features and fancy new algorithms go. When eventually, 3.3.N is stable enough, it becomese 3.4.0 and again, new features go into the odd numbered release 3.5.0. This would be valuable I think because there are times when bugs appear in 3.0 that it would be nice to fix - without having to suffer the growing pains of 3.1 The obvious downside is that bug fixes have to be applied to two releases at once - but I think that's a reasonable price to pay for the benefits of a progressively more stable current release. That in turn means that you don't have to worry so much about converting the current odd-numbered release into an even numbered one for the sake of fixing bugs. I don't think this approach is a good idea for small projects in their early stages - but for something as large and long-lived as Mesa, I think it's a good idea. One SPECIFIC reason to go this way is that it gives people writing low level drivers a stable (even numbered) platform to work with. What does everyone else think about this idea? Raytheon Systems Inc. (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.hti.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] experimental branch
Brian Paul wrote: > > Keith, I'd like to hear what your longer-term coding plans are. Do > you see a milestone in your work for a 3.1 release? I think you could say that the latest batch of changes pretty much represents the end of a certain line of improvements. I know Holger is doing some 3dnow assembly in support of those changes, and there is other tweaking possible. Apart from those issues I'm happy to draw a line under what's been done so far and call it a unit. My next change to the Mesa core will probably be to provide some support for floating point colors if that is what we're getting from the API. I'm also interested in trying to clean up the way we handle vertex copying at the end of an immediate vb, opening up the fast path to the immediate pipeline, and fixing some other immediate mode issues of my own making. I don't think these changes are worth delaying a release for. So I think I've done my last major chunk of coding for this release - just clean-up, bugfixes and everybody else's work to go... Keith ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] experimental branch
Keith Whitwell wrote: > > "C.J. Beyer" wrote: > > > > > Ah, I'd was curious why there'd been no cvs updates in so long! It the > > > experimental-1 branch where development occurs, then? A note about this > > > on the website would be helpful! > > > > Actually, I was under the impression that the experimental branch was > just > > a temporary thing until Mesa-3.1-beta2 was released. Now that beta2 > > has been released the development tree is no longer necessary. > > Keith? > > I defer to Brian on this, but I can vouch that some of the code in there > is pretty raw. A week or so of stabilization is required for my stuff > at least. > > The real question is whether Brian wants the next release version to > include the new code or not. I don't have a date in mind for the next beta release. I'd like to keep the mainline code pretty much stable. After Keith has tested and debugged his code branch with most of the demo/sample programs, Quake, etc. then merging into the mainline is appropriate. In other words, when people download and test the latest CVS snapshot I'd like them to see forward progress (fewer bugs, better speed) rather than find newly broken code. I was planning on doing more conformance testing/fixing pretty soon. I'd rather do that with stable, mainline code. Keith, I'd like to hear what your longer-term coding plans are. Do you see a milestone in your work for a 3.1 release? -Brian -- Brian PaulAvid Technology / Softimage [EMAIL PROTECTED] ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] experimental branch
"C.J. Beyer" wrote: > > > Ah, I'd was curious why there'd been no cvs updates in so long! It the > > experimental-1 branch where development occurs, then? A note about this > > on the website would be helpful! > > Actually, I was under the impression that the experimental branch was just > a temporary thing until Mesa-3.1-beta2 was released. Now that beta2 > has been released the development tree is no longer necessary. > Keith? I defer to Brian on this, but I can vouch that some of the code in there is pretty raw. A week or so of stabilization is required for my stuff at least. The real question is whether Brian wants the next release version to include the new code or not. Keith ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
