Re: [Mesa-dev] [Mesa3d-dev] Separate demos repository
Eric Anholt wrote: On Thu, 20 May 2010 15:45:00 -0400, Kristian Høgsberg wrote: On Thu, May 20, 2010 at 3:18 PM, Eric Anholt wrote: On Wed, 28 Apr 2010 11:00:45 +, José Fonseca wrote: Ping. Could someone with administrative rights on fdo please make an empty git://anongit.freedesktop.org/mesa/demos repos, so that we can push this branch into it? Jose Sorry for the delay. I wanted to get a few things done right when making the new repo: 1) Don't include all of the Mesa history to keep repo size down. 2) Keep history of the changes to the demos so annotate works. 3) Move the demos to src/ so people just coming to the project see a normal-looking tree. This sure sounded easy with git-filter-branch. We'd done something like this with git-split for xcb, and git-filter-branch looked basically like git-split but with more options. The ugly part is that the tree-filter takes a very long time, but git mv (unlike git rm) requires a checked-out tree so you can't index-filter it. Here's how the history I've pushed came about. I started with: commit 1391db428fe7b8f3d1c078da98dc1a231b54347f Author: Wiktor Janas Date: Tue May 4 19:50:26 2010 +0200 u_blitter: fix creating fragment shaders See FDO bug #27887. Signed-off-by: Marek Olšák And then: # Remove everything in src/ git filter-branch --index-filter "git rm -rf --cached src" HEAD # Remove all the do-nothing commits that now exist git filter-branch --prune-empty HEAD # Remove the nouveau import commit that was now empty, and confused the next filter git filter-branch --parent-filter "sed 's|-p d57c2aff039d2a1422d0bc4d8e2b850c33d7e95c||'" HEAD # Now actually move progs/ to src/ git filter-branch -f --index-filter \ 'git ls-files -s | sed "s-\tprogs/-\tsrc/-" | GIT_INDEX_FILE=$GIT_INDEX_FILE.new \ git update-index --index-info && mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD Yuck. Anyway, that resulting tree plus the changes I had in the other tree rebased on it is now pushed to: git+ssh://git.freedesktop.org/git/mesa/demos I think commit messages are hooked up, too. Very nice... though, shoudn't we also drop the docs, doxygen, include and configs subdirectories? Yeah, probably. I'm calling it a night at this point though. Also fixed up the generated Makefile in revision control, pulled in the changes from Mesa master that weren't in (except for the last cygwin fix, and getprocaddress still needs work). Looks pretty good, Eric. Don't worry about the getprocaddress test for now, just omit it from the build. There's a bunch of other clean-ups to be done (ex: convert more programs to use glew) that I'll try to do in my spare time. Are we OK to start committing there? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: gallium-front-ccw branch
On Wed, 2010-05-19 at 05:29 -0700, Keith Whitwell wrote: > So, the front vs. ccw feature branch is working pretty well for softpipe > and llvmpipe. > > I've got some documentation fixup to do, but it would also be good if > the various driver owners could take a look at the changes there. I've > tried to adjust each driver correctly, but it's likely that mistakes > have crept in... OK, interpreting silence as approval... Let me know if there are any problems. Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: gallium-front-ccw branch
On Fri, 2010-05-21 at 07:45 -0700, Keith Whitwell wrote: > On Wed, 2010-05-19 at 05:29 -0700, Keith Whitwell wrote: > > So, the front vs. ccw feature branch is working pretty well for softpipe > > and llvmpipe. > > > > I've got some documentation fixup to do, but it would also be good if > > the various driver owners could take a look at the changes there. I've > > tried to adjust each driver correctly, but it's likely that mistakes > > have crept in... > > OK, interpreting silence as approval... Let me know if there are any > problems. I had no time to check the code, but I think the general idea good FWIW. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa3d-dev] Separate demos repository
On Fri, 2010-05-21 at 07:34 -0700, Brian Paul wrote: > Eric Anholt wrote: > > On Thu, 20 May 2010 15:45:00 -0400, Kristian Høgsberg > > wrote: > >> On Thu, May 20, 2010 at 3:18 PM, Eric Anholt wrote: > >>> On Wed, 28 Apr 2010 11:00:45 +, José Fonseca > >>> wrote: > Ping. > > Could someone with administrative rights on fdo please make an empty > git://anongit.freedesktop.org/mesa/demos repos, so that we can push this > branch into it? > > Jose > >>> Sorry for the delay. I wanted to get a few things done right when > >>> making the new repo: > >>> > >>> 1) Don't include all of the Mesa history to keep repo size down. > >>> 2) Keep history of the changes to the demos so annotate works. > >>> 3) Move the demos to src/ so people just coming to the project see a > >>> normal-looking tree. > >>> > >>> This sure sounded easy with git-filter-branch. We'd done something like > >>> this with git-split for xcb, and git-filter-branch looked basically like > >>> git-split but with more options. The ugly part is that the tree-filter > >>> takes a very long time, but git mv (unlike git rm) requires a > >>> checked-out tree so you can't index-filter it. Here's how the history > >>> I've pushed came about. I started with: > >>> > >>> commit 1391db428fe7b8f3d1c078da98dc1a231b54347f > >>> Author: Wiktor Janas > >>> Date: Tue May 4 19:50:26 2010 +0200 > >>> > >>>u_blitter: fix creating fragment shaders > >>> > >>>See FDO bug #27887. > >>> > >>>Signed-off-by: Marek Olšák > >>> > >>> And then: > >>> > >>> # Remove everything in src/ > >>> git filter-branch --index-filter "git rm -rf --cached src" HEAD > >>> # Remove all the do-nothing commits that now exist > >>> git filter-branch --prune-empty HEAD > >>> # Remove the nouveau import commit that was now empty, and confused the > >>> next filter > >>> git filter-branch --parent-filter "sed 's|-p > >>> d57c2aff039d2a1422d0bc4d8e2b850c33d7e95c||'" HEAD > >>> # Now actually move progs/ to src/ > >>> git filter-branch -f --index-filter \ > >>>'git ls-files -s | sed "s-\tprogs/-\tsrc/-" | > >>> GIT_INDEX_FILE=$GIT_INDEX_FILE.new \ > >>> git update-index --index-info && > >>> mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD > >>> > >>> Yuck. > >>> > >>> Anyway, that resulting tree plus the changes I had in the other tree > >>> rebased on it is now pushed to: > >>> > >>> git+ssh://git.freedesktop.org/git/mesa/demos > >>> > >>> I think commit messages are hooked up, too. > >> Very nice... though, shoudn't we also drop the docs, doxygen, include > >> and configs subdirectories? > > > > Yeah, probably. I'm calling it a night at this point though. Also > > fixed up the generated Makefile in revision control, pulled in the > > changes from Mesa master that weren't in (except for the last cygwin > > fix, and getprocaddress still needs work). > > Looks pretty good, Eric. > > Don't worry about the getprocaddress test for now, just omit it from > the build. > > There's a bunch of other clean-ups to be done (ex: convert more > programs to use glew) that I'll try to do in my spare time. > > Are we OK to start committing there? I'm OK with that. I also need to get windows build going on again, but I'll do that as time permits as well. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 28206] New: [PATCH mesa] Add __DragonFly__ in querymatrix.c for fpclassify()
https://bugs.freedesktop.org/show_bug.cgi?id=28206 Summary: [PATCH mesa] Add __DragonFly__ in querymatrix.c for fpclassify() Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: other Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: davs...@gmail.com Created an attachment (id=35785) --> (https://bugs.freedesktop.org/attachment.cgi?id=35785) [PATCH mesa] Add __DragonFly__ in querymatrix.c for fpclassify() Add DragonFly BSD to the list of OSes for which fpclassify() is already available. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 28206] [PATCH mesa] Add __DragonFly__ in querymatrix.c for fpclassify()
https://bugs.freedesktop.org/show_bug.cgi?id=28206 Alan Coopersmith changed: What|Removed |Added Attachment #35785|application/octet-stream|text/plain mime type|| Attachment #35785|0 |1 is patch|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: gallium-front-ccw branch
On Fri, May 21, 2010 at 8:00 AM, José Fonseca wrote: > On Fri, 2010-05-21 at 07:45 -0700, Keith Whitwell wrote: >> On Wed, 2010-05-19 at 05:29 -0700, Keith Whitwell wrote: >> > So, the front vs. ccw feature branch is working pretty well for softpipe >> > and llvmpipe. >> > >> > I've got some documentation fixup to do, but it would also be good if >> > the various driver owners could take a look at the changes there. I've >> > tried to adjust each driver correctly, but it's likely that mistakes >> > have crept in... >> >> OK, interpreting silence as approval... Let me know if there are any >> problems. > > I had no time to check the code, but I think the general idea good FWIW. Just tested, works excellently over here. The actual patch to r300g was perfect. (I *knew* commenting that code block would help somebody!) ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 28206] [PATCH mesa] Add __DragonFly__ in querymatrix.c for fpclassify()
https://bugs.freedesktop.org/show_bug.cgi?id=28206 Brian Paul changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Brian Paul 2010-05-21 09:01:13 PDT --- Committed. Thanks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Reducing get.c size (and get_es1.c and get_es2.c)
On 11.05.2010 20:08, Kristian Høgsberg wrote: > 2010/5/11 Brian Paul : >> Kristian Høgsberg wrote: >>> 2010/5/6 Kristian Høgsberg : Hi, Ok, I suppose this is not the most pressing issue in mesa, but I was toying with an idea of how to reduce get.c size and integrate get_es1.c and get_es2.c and I had to try it out. Of course it ended up being a bigger project and took a couple of days, but in the end I think it turned out to be a worthwhile effort. The result is the two patches on the get-optimagix branch in my personal mesa repo: http://cgit.freedesktop.org/~krh/mesa/log/?h=get-optimagix >>> I've updated the patch on the branch here, but I'm still not going to >>> send it to the list (it's 500k and most of which deletes generated >>> code). But I've been going back and forth with Brian about the patch >>> a few times and we found a few bugs and made the code a little faster. >>> Brian cooked up a small micro-benchmark for the glGet*v() functions >>> and it turned out that the code was actually slower than the old >>> generated code. With a little tweaking of the table lookup and adding >>> a couple of likely() annotations, I got the code from 30s to 23s, >>> where the old code would take 15s. That's still 17 million gets per >>> second, so I doubt the new code is going to be a bottleneck. >> It looks like piglit's texunits test is failing, compared to Mesa/master. >> It may be an issue with flush-current when getting the curren texture >> coords. > > Fixed, didn't initialize 'unit' in find_custom_value(). > >> I'd like to see comments on more of the internal functions, like >> find_value() to describe the parameters in/out. > > Ok, done. > >> Also, could you replace the #ifdef DEBUG stuff with a separate #ifdef >> GET_DEBUG or similar to avoid printing the hash table collision info all the >> time in debug builds? > > Sure, done. > >> There hasn't been any other feedback so I'd so go ahead and commit it to >> master when these things are fixed. > > Done, and I updated the table with your recent feedback changes. Just a small nitpick, but I got buried under roughly 300 compiler warnings (missing initializer). Now that looks pretty harmless, but I didn't feel like fixing all 300 occasions in the table manually :-(. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: gallium-msaa branch merge
On Tue, May 18, 2010 at 7:04 PM, Roland Scheidegger wrote: > Hi, > > I plan to merge the gallium-msaa branch to master soon. > It's actually a bit of a misnomer since the conceptually more important > changes in there are about blits... > > Here's a short summary what this is about: > blits now operate on resources, not surfaces (surface_copy/fill -> > resource_copy/fill_region). Note that overlapping blits are no longer > permitted (half the code always assumed this wasn't the case), and these > functions are now mandatory (most of the code using these just checked > for their presence and if not used util_surface_copy instead, hence it > seems cleaner if drivers plug that in themselves, which some already did). > Also, there's an assumption that resource_copy_region works regardless > of bind flags (at least for texture targets, actually might also need to > work for buffers for "modern" drivers in the future not sure yet), hence > there are no longer any PIPE_BIND_BLIT flags (which were quite magic to > begin with, since a lot of the code could end up with a quad blit which > really wants RENDER_TARGET/SAMPLER_VIEW bind flags instead). > It is possible some of the drivers implementation are a bit suboptimal > now, as they still use surfaces internally for easier migration (svga, > r300g, nouveau might particularly benefit from some cleanup). > If a driver implements this just with util_resource_copy_region, it is > possible there are performance regressions, since some (certainly not > all) state trackers used a quad blitter instead if this wasn't available. > The u_blit code still uses a pipe_surface as destination, which should > probably be changed at some point too but the change was already big > enough imho. > > Historically, blits had to operate on surfaces IIRC since there actually > were surfaces in gallium not backed by a pipe_resource (then > pipe_texture) but those are gone. So get_tex_surface() should actually > be viewed as the analogous function to create_sampler_view() (and yes it > will migrate to context too and probably renamed to something else), it > creates a view of a resource (the pipe_surface) to be used as a render > target (color or depth/stencil). > > The msaa changes are fairly minimal, there's a new context function to > set the sample mask (all drivers have dummy implementations), plus some > bits for sample to coverage etc. And a explicit resource_resolve > function which is defined as the only way to resolve a multisampled > resource, but so far no driver implements multisampling (and the mesa > state tracker won't use it neither). > Just including nouveau ML in CC in case someone missed that merge, as I think there is some work to be done in nouveau driver. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Reducing get.c size (and get_es1.c and get_es2.c)
Roland Scheidegger wrote: On 11.05.2010 20:08, Kristian Høgsberg wrote: 2010/5/11 Brian Paul : Kristian Høgsberg wrote: 2010/5/6 Kristian Høgsberg : Hi, Ok, I suppose this is not the most pressing issue in mesa, but I was toying with an idea of how to reduce get.c size and integrate get_es1.c and get_es2.c and I had to try it out. Of course it ended up being a bigger project and took a couple of days, but in the end I think it turned out to be a worthwhile effort. The result is the two patches on the get-optimagix branch in my personal mesa repo: http://cgit.freedesktop.org/~krh/mesa/log/?h=get-optimagix I've updated the patch on the branch here, but I'm still not going to send it to the list (it's 500k and most of which deletes generated code). But I've been going back and forth with Brian about the patch a few times and we found a few bugs and made the code a little faster. Brian cooked up a small micro-benchmark for the glGet*v() functions and it turned out that the code was actually slower than the old generated code. With a little tweaking of the table lookup and adding a couple of likely() annotations, I got the code from 30s to 23s, where the old code would take 15s. That's still 17 million gets per second, so I doubt the new code is going to be a bottleneck. It looks like piglit's texunits test is failing, compared to Mesa/master. It may be an issue with flush-current when getting the curren texture coords. Fixed, didn't initialize 'unit' in find_custom_value(). I'd like to see comments on more of the internal functions, like find_value() to describe the parameters in/out. Ok, done. Also, could you replace the #ifdef DEBUG stuff with a separate #ifdef GET_DEBUG or similar to avoid printing the hash table collision info all the time in debug builds? Sure, done. There hasn't been any other feedback so I'd so go ahead and commit it to master when these things are fixed. Done, and I updated the table with your recent feedback changes. Just a small nitpick, but I got buried under roughly 300 compiler warnings (missing initializer). Now that looks pretty harmless, but I didn't feel like fixing all 300 occasions in the table manually :-(. I'll take a crack at fixing that... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: gallium-msaa branch merge
Ok, after looking at how some other drivers were updated, I thought nouveau needed bigger changes than that. Jakob just pushed a simple build fix, and now nv50 builds and runs (almost ;)). I just noticed 5 piglit regressions : fbo/fbo-copypix fbo/fbo-copyteximage general/scissor-copypixels texturing/depth-level-clamp texturing/texredefine And I am not sure how important is the TODO mentioned in the commit log below. commit b59b23a51dc17da59ccff0b3f8a73009056746e5 Author: Roland Scheidegger Date: Mon May 17 21:28:14 2010 +0200 nouveau: adapt to interface changes this probably needs further cleanup (just getting a surface for the resource seems quite nonoptimal and potentially cause unnecessary copies I think) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa3d-dev] Separate demos repository
On Fri, 21 May 2010 08:34:59 -0600, Brian Paul wrote: > Eric Anholt wrote: > > On Thu, 20 May 2010 15:45:00 -0400, Kristian Høgsberg > > wrote: > >> On Thu, May 20, 2010 at 3:18 PM, Eric Anholt wrote: > >>> On Wed, 28 Apr 2010 11:00:45 +, José Fonseca > >>> wrote: > Ping. > > Could someone with administrative rights on fdo please make an empty > git://anongit.freedesktop.org/mesa/demos repos, so that we can push this > branch into it? > > Jose > >>> Sorry for the delay. I wanted to get a few things done right when > >>> making the new repo: > >>> > >>> 1) Don't include all of the Mesa history to keep repo size down. > >>> 2) Keep history of the changes to the demos so annotate works. > >>> 3) Move the demos to src/ so people just coming to the project see a > >>> normal-looking tree. > >>> > >>> This sure sounded easy with git-filter-branch. We'd done something like > >>> this with git-split for xcb, and git-filter-branch looked basically like > >>> git-split but with more options. The ugly part is that the tree-filter > >>> takes a very long time, but git mv (unlike git rm) requires a > >>> checked-out tree so you can't index-filter it. Here's how the history > >>> I've pushed came about. I started with: > >>> > >>> commit 1391db428fe7b8f3d1c078da98dc1a231b54347f > >>> Author: Wiktor Janas > >>> Date: Tue May 4 19:50:26 2010 +0200 > >>> > >>>u_blitter: fix creating fragment shaders > >>> > >>>See FDO bug #27887. > >>> > >>>Signed-off-by: Marek Olšák > >>> > >>> And then: > >>> > >>> # Remove everything in src/ > >>> git filter-branch --index-filter "git rm -rf --cached src" HEAD > >>> # Remove all the do-nothing commits that now exist > >>> git filter-branch --prune-empty HEAD > >>> # Remove the nouveau import commit that was now empty, and confused the > >>> next filter > >>> git filter-branch --parent-filter "sed 's|-p > >>> d57c2aff039d2a1422d0bc4d8e2b850c33d7e95c||'" HEAD > >>> # Now actually move progs/ to src/ > >>> git filter-branch -f --index-filter \ > >>>'git ls-files -s | sed "s-\tprogs/-\tsrc/-" | > >>> GIT_INDEX_FILE=$GIT_INDEX_FILE.new \ > >>> git update-index --index-info && > >>> mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD > >>> > >>> Yuck. > >>> > >>> Anyway, that resulting tree plus the changes I had in the other tree > >>> rebased on it is now pushed to: > >>> > >>> git+ssh://git.freedesktop.org/git/mesa/demos > >>> > >>> I think commit messages are hooked up, too. > >> Very nice... though, shoudn't we also drop the docs, doxygen, include > >> and configs subdirectories? > > > > Yeah, probably. I'm calling it a night at this point though. Also > > fixed up the generated Makefile in revision control, pulled in the > > changes from Mesa master that weren't in (except for the last cygwin > > fix, and getprocaddress still needs work). > > Looks pretty good, Eric. > > Don't worry about the getprocaddress test for now, just omit it from > the build. > > There's a bunch of other clean-ups to be done (ex: convert more > programs to use glew) that I'll try to do in my spare time. > > Are we OK to start committing there? Sounds like it. I've removed the demos that are successfully building there from the main Mesa repo. Hopefully for the others, people can fix the build in the new repo instead of continuing in Mesa. Notably, I haven't managed to do cygwin native GL yet, which I'd need to get the wgl bits up, and I don't have a real VG to test against for egl/openvg (ShivaVG doesn't have the EGL glue and doesn't install headers.) pgpteQofx2HoH.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: gallium-msaa branch merge
On Tue, 2010-05-18 at 10:04 -0700, Roland Scheidegger wrote: > Hi, > > I plan to merge the gallium-msaa branch to master soon. > It's actually a bit of a misnomer since the conceptually more important > changes in there are about blits... > > Here's a short summary what this is about: > blits now operate on resources, not surfaces (surface_copy/fill -> > resource_copy/fill_region). Note that overlapping blits are no longer > permitted (half the code always assumed this wasn't the case), and these > functions are now mandatory (most of the code using these just checked > for their presence and if not used util_surface_copy instead, hence it > seems cleaner if drivers plug that in themselves, which some already did). > Also, there's an assumption that resource_copy_region works regardless > of bind flags (at least for texture targets, actually might also need to > work for buffers for "modern" drivers in the future not sure yet), hence > there are no longer any PIPE_BIND_BLIT flags (which were quite magic to > begin with, since a lot of the code could end up with a quad blit which > really wants RENDER_TARGET/SAMPLER_VIEW bind flags instead). I didn't have time to look at the branch in detail, but all the above makes sense to me FWIW. > It is possible some of the drivers implementation are a bit suboptimal > now, as they still use surfaces internally for easier migration (svga, > r300g, nouveau might particularly benefit from some cleanup). > If a driver implements this just with util_resource_copy_region, it is > possible there are performance regressions, since some (certainly not > all) state trackers used a quad blitter instead if this wasn't available. > The u_blit code still uses a pipe_surface as destination, which should > probably be changed at some point too but the change was already big > enough imho. > > Historically, blits had to operate on surfaces IIRC since there actually > were surfaces in gallium not backed by a pipe_resource (then > pipe_texture) but those are gone. So get_tex_surface() should actually > be viewed as the analogous function to create_sampler_view() (and yes it > will migrate to context too and probably renamed to something else), it > creates a view of a resource (the pipe_surface) to be used as a render > target (color or depth/stencil). > > The msaa changes are fairly minimal, there's a new context function to > set the sample mask (all drivers have dummy implementations), plus some > bits for sample to coverage etc. And a explicit resource_resolve > function which is defined as the only way to resolve a multisampled > resource, but so far no driver implements multisampling (and the mesa > state tracker won't use it neither). There was some rudimentary MSAA support in mesa/st before. How does that stand now? Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa3d-dev] Separate demos repository
On Fri, May 21, 2010 at 8:42 PM, Eric Anholt wrote: > On Fri, 21 May 2010 08:34:59 -0600, Brian Paul wrote: >> Eric Anholt wrote: >> > On Thu, 20 May 2010 15:45:00 -0400, Kristian Høgsberg >> > wrote: >> >> On Thu, May 20, 2010 at 3:18 PM, Eric Anholt wrote: >> >>> On Wed, 28 Apr 2010 11:00:45 +, José Fonseca >> >>> wrote: >> Ping. >> >> Could someone with administrative rights on fdo please make an empty >> git://anongit.freedesktop.org/mesa/demos repos, so that we can push this >> branch into it? >> >> Jose >> >>> Sorry for the delay. I wanted to get a few things done right when >> >>> making the new repo: >> >>> >> >>> 1) Don't include all of the Mesa history to keep repo size down. >> >>> 2) Keep history of the changes to the demos so annotate works. >> >>> 3) Move the demos to src/ so people just coming to the project see a >> >>> normal-looking tree. >> >>> >> >>> This sure sounded easy with git-filter-branch. We'd done something like >> >>> this with git-split for xcb, and git-filter-branch looked basically like >> >>> git-split but with more options. The ugly part is that the tree-filter >> >>> takes a very long time, but git mv (unlike git rm) requires a >> >>> checked-out tree so you can't index-filter it. Here's how the history >> >>> I've pushed came about. I started with: >> >>> >> >>> commit 1391db428fe7b8f3d1c078da98dc1a231b54347f >> >>> Author: Wiktor Janas >> >>> Date: Tue May 4 19:50:26 2010 +0200 >> >>> >> >>> u_blitter: fix creating fragment shaders >> >>> >> >>> See FDO bug #27887. >> >>> >> >>> Signed-off-by: Marek Olšák >> >>> >> >>> And then: >> >>> >> >>> # Remove everything in src/ >> >>> git filter-branch --index-filter "git rm -rf --cached src" HEAD >> >>> # Remove all the do-nothing commits that now exist >> >>> git filter-branch --prune-empty HEAD >> >>> # Remove the nouveau import commit that was now empty, and confused the >> >>> next filter >> >>> git filter-branch --parent-filter "sed 's|-p >> >>> d57c2aff039d2a1422d0bc4d8e2b850c33d7e95c||'" HEAD >> >>> # Now actually move progs/ to src/ >> >>> git filter-branch -f --index-filter \ >> >>> 'git ls-files -s | sed "s-\tprogs/-\tsrc/-" | >> >>> GIT_INDEX_FILE=$GIT_INDEX_FILE.new \ >> >>> git update-index --index-info && >> >>> mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD >> >>> >> >>> Yuck. >> >>> >> >>> Anyway, that resulting tree plus the changes I had in the other tree >> >>> rebased on it is now pushed to: >> >>> >> >>> git+ssh://git.freedesktop.org/git/mesa/demos >> >>> >> >>> I think commit messages are hooked up, too. >> >> Very nice... though, shoudn't we also drop the docs, doxygen, include >> >> and configs subdirectories? >> > >> > Yeah, probably. I'm calling it a night at this point though. Also >> > fixed up the generated Makefile in revision control, pulled in the >> > changes from Mesa master that weren't in (except for the last cygwin >> > fix, and getprocaddress still needs work). >> >> Looks pretty good, Eric. >> >> Don't worry about the getprocaddress test for now, just omit it from >> the build. >> >> There's a bunch of other clean-ups to be done (ex: convert more >> programs to use glew) that I'll try to do in my spare time. >> >> Are we OK to start committing there? > > Sounds like it. I've removed the demos that are successfully building > there from the main Mesa repo. Hopefully for the others, people can fix > the build in the new repo instead of continuing in Mesa. Notably, I > haven't managed to do cygwin native GL yet, which I'd need to get the > wgl bits up, and I don't have a real VG to test against for egl/openvg > (ShivaVG doesn't have the EGL glue and doesn't install headers.) You can use the Gallium OpenVG implementation. ./configure --enable-egl --enable-gallium-intel --with-state-trackers=egl,vega If you don't want to install you need to do this: export EGL_DRIVERS_PATH=$PWD/lib/egl Otherwise just install it, it even installs a vg.pc. The biggest thing tho is that you need to export EGL_SOFTWARE=true if you are on i965 because the hardware driver will hang your machine. export EGL_SOFTWARE=true Cheers Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
