Re: [Mesa3d-dev] r300g: hack around issue with doom3 and 0 stride
> r300g: hack around issue with doom3 and 0 stride > This is most likely a bug in the mesa state tracker, but do the quick hack > for now to avoid the divide by 0. This is not a bug: stride 0 means that the vertex attribute is constant for all vertices. It is not a special value either: advancing the vertex attribute pointer by 0 will naturally result in always fetching the same value. Thus, the patch is not likely to be correct: you should instead either program stride 0 to the hardware if supported, or fetch the vertex attribute with the CPU (I think it is always in a user buffer, but not sure, maybe OpenGL allows explicitly specifying a VBO with stride 0) and use whatever means Radeon provides to set a constant vertex attribute (e.g. nVidia GPUs have a FIFO method exactly for that). -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Sat, Apr 10, 2010 at 4:52 PM, Roland Scheidegger wrote: > On 10.04.2010 17:10, Keith Whitwell wrote: >> On Sat, Apr 10, 2010 at 4:05 PM, Keith Whitwell >> wrote: >>> On Sat, Apr 10, 2010 at 3:49 PM, Roland Scheidegger >>> wrote: On 10.04.2010 16:43, Chia-I Wu wrote: > On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell > wrote: >> Hmm, not sure whether to merge or squash-merge this branch. Any >> thoughts? > The conversion to pipe_resource seems to be done by components. Maybe a > new > branch that reorganize (git rebase -i) the commits in gallium-resources > and > merge the new branch to master? I've never used git rebase -i but I'm not convinced that can give something sensible. It wasn't done strictly by components, with a couple merges from master (and gallium-buffer-usage-cleanup) in between and fixes for already converted things... >>> Squash merge it is. >> >> Somewhat arbitrary decision to avoid stretching this out any further. >> >> I don't think the history that was on the branch was very useful, nor >> does inventing history seem likely to help people searching for >> regressions, etc. The branch is effectively an atomic change, so >> let's deal with it like that... > > Yeah, you're right. Thinking about it, parts of it were always broken > throughout the life of the branch or didn't even build, so squash merge > makes sense. Glad it's merged - no more conflicts fixing for merges from > master :-). Indeed. Keith -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On 10.04.2010 17:10, Keith Whitwell wrote: > On Sat, Apr 10, 2010 at 4:05 PM, Keith Whitwell > wrote: >> On Sat, Apr 10, 2010 at 3:49 PM, Roland Scheidegger >> wrote: >>> On 10.04.2010 16:43, Chia-I Wu wrote: On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell wrote: > Hmm, not sure whether to merge or squash-merge this branch. Any thoughts? The conversion to pipe_resource seems to be done by components. Maybe a new branch that reorganize (git rebase -i) the commits in gallium-resources and merge the new branch to master? >>> I've never used git rebase -i but I'm not convinced that can give >>> something sensible. It wasn't done strictly by components, with a couple >>> merges from master (and gallium-buffer-usage-cleanup) in between and >>> fixes for already converted things... >>> >> Squash merge it is. > > Somewhat arbitrary decision to avoid stretching this out any further. > > I don't think the history that was on the branch was very useful, nor > does inventing history seem likely to help people searching for > regressions, etc. The branch is effectively an atomic change, so > let's deal with it like that... Yeah, you're right. Thinking about it, parts of it were always broken throughout the life of the branch or didn't even build, so squash merge makes sense. Glad it's merged - no more conflicts fixing for merges from master :-). Roland -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Provide dri shared library building and SDK installation.
I haven't been following this very closely, so apologies if I'm going over established ground. This patch appears to create new libraries from some subset of Mesa's internals. At a guess you're selecting some internal interface(s) within mesa to become the public API of those libraries? I'm pretty sure that's not something we're trying to achieve in this project. We have public APIs which we respect and implement, and which are maintained and evolved under the Khronos umbrella. We have a strong driver-level interface (ie gallium) which we benefit greatly from being rev as fast and as hard as we can, to adapt to our evolving understanding of the problem space. We really don't want to subject that interface to the strictures that come with becoming a public API or ABI. We have a third interface, the Mesa driver interface, which may appear relatively stable, but which is more accurately described as neglected, veering towards deprecated. The shortcomings of this interface, in particular its porous nature and inappropriate abstraction level, were major catalysts provoking the development of gallium. Those shortcomings would also make it less than appropriate as a public API. At some point in the future, that interface will either roar back into rapid evolution or truly be deprecated in favour of either gallium or a low-level, legacy-free GL3/4 subset from Khronos. I can't easily tell from your patch what interfaces these new libraries have, or what expectations there would be for maintaining compatibility on those interfaces going forward. I'd like to see that spelled out explicitly. Without investigating further, I can say I'm not aware of any interface within Mesa which we'd be happy to promote to a public interface, nor one which we'd be happy to accept extra restrictions on in terms of compatibility. Keith On Fri, Apr 9, 2010 at 11:59 PM, Luc Verhaegen wrote: > Patch cherry-picked from my dri-sdk-7.8 branch against current head > (edb5253dfa). An earlier full build through of all drivers (except > nouveau, i will play with its expansive libdrm dependencies later) > showed it to be an exact match still. > > This patch, while not harming or hampering anything or anyone, gives us > the ability to maintain and build DRI drivers out of tree for those so > inclined. Build system additions only. No adverse effects. Everybody > wins. > > I intend to provide changes as needed, I hope to at least manage to > maintain released versions in the long term. > > For those wanting a test run, please check out the 7.8 version of the > SDK and the drivers in my cgit.freedesktop.org repos. > > Luc Verhaegen. > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Sat, Apr 10, 2010 at 4:05 PM, Keith Whitwell wrote: > On Sat, Apr 10, 2010 at 3:49 PM, Roland Scheidegger > wrote: >> On 10.04.2010 16:43, Chia-I Wu wrote: >>> On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell >>> wrote: Hmm, not sure whether to merge or squash-merge this branch. Any thoughts? >>> The conversion to pipe_resource seems to be done by components. Maybe a new >>> branch that reorganize (git rebase -i) the commits in gallium-resources and >>> merge the new branch to master? >> >> I've never used git rebase -i but I'm not convinced that can give >> something sensible. It wasn't done strictly by components, with a couple >> merges from master (and gallium-buffer-usage-cleanup) in between and >> fixes for already converted things... >> > > Squash merge it is. Somewhat arbitrary decision to avoid stretching this out any further. I don't think the history that was on the branch was very useful, nor does inventing history seem likely to help people searching for regressions, etc. The branch is effectively an atomic change, so let's deal with it like that... Keith -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Sat, Apr 10, 2010 at 3:49 PM, Roland Scheidegger wrote: > On 10.04.2010 16:43, Chia-I Wu wrote: >> On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell >> wrote: >>> Hmm, not sure whether to merge or squash-merge this branch. Any thoughts? >> The conversion to pipe_resource seems to be done by components. Maybe a new >> branch that reorganize (git rebase -i) the commits in gallium-resources and >> merge the new branch to master? > > I've never used git rebase -i but I'm not convinced that can give > something sensible. It wasn't done strictly by components, with a couple > merges from master (and gallium-buffer-usage-cleanup) in between and > fixes for already converted things... > Squash merge it is. Keith -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Mesa-dev] Mesa dev list has been moved to fd.o
On Sat, Apr 10, 2010 at 6:38 AM, Brian Paul wrote: > Thanks to Tollef and Jesse, everyone should now be subscribed to the mesa-dev > list at freedesktop.org. You should see this message twice if you're on the > new list. > > I'll probably shut down the old list next week when I get back from a little > time off... Are mesa3d-announce or mesa3d-user moving? I'm just asking because I'm going let the gmane people know to change the address. -- Dan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On 10.04.2010 16:43, Chia-I Wu wrote: > On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell > wrote: >> Hmm, not sure whether to merge or squash-merge this branch. Any thoughts? > The conversion to pipe_resource seems to be done by components. Maybe a new > branch that reorganize (git rebase -i) the commits in gallium-resources and > merge the new branch to master? I've never used git rebase -i but I'm not convinced that can give something sensible. It wasn't done strictly by components, with a couple merges from master (and gallium-buffer-usage-cleanup) in between and fixes for already converted things... Roland -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell wrote: > Hmm, not sure whether to merge or squash-merge this branch. Any thoughts? The conversion to pipe_resource seems to be done by components. Maybe a new branch that reorganize (git rebase -i) the commits in gallium-resources and merge the new branch to master? -- o...@lunarg.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On 10.04.2010 14:00, Keith Whitwell wrote: > Hmm, not sure whether to merge or squash-merge this branch. Any thoughts? I'm no big fan of squash merge but the history of the normal merge won't be nice neither. Tough call, though I'd prefer a normal merge. Roland -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Mesa dev list has been moved to fd.o
Thanks to Tollef and Jesse, everyone should now be subscribed to the mesa-dev list at freedesktop.org. You should see this message twice if you're on the new list. I'll probably shut down the old list next week when I get back from a little time off... -Brian -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
Hmm, not sure whether to merge or squash-merge this branch. Any thoughts? Keith -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Sat, Apr 10, 2010 at 12:39 PM, Keith Whitwell wrote: > On Sat, Apr 10, 2010 at 12:36 PM, Keith Whitwell > wrote: >> On Sat, Apr 10, 2010 at 6:59 AM, Chia-I Wu wrote: >>> On Fri, Apr 9, 2010 at 9:07 PM, Keith Whitwell wrote: On Fri, 2010-04-09 at 03:43 -0700, Keith Whitwell wrote: > On Thu, 2010-04-08 at 15:20 -0700, Marek Olšák wrote: > > On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell > > wrote: > > > > OK, it seems like quite a few cases had migrated to the new > > > > buffer_map_range() behaviour. I've looked at all I can find > > and moved > > them back to the old behaviour. > > > > glean is passing now on softpipe. > > > > There's now an assertion failure in pipe_buffer_flush_mapped_range. > > Given a mapped range, the current behavior in debug build doesn't > > allow to flush its subrange if it doesn't touch the last byte of the > > range. The attached patch fixes that and changes u_uploadmgr for the > > mapped and flushed ranges to match. Please review. > > > > Other than that, it's stable as master. Thank you very much. > > OK, if nobody chimes in, let's look at merging this to master in the > next day or so. > I've made a final merge of master into gallium-resources. Please try it out and report/fix any issues. This will be merged tomorrow. >>> Texturing in i915g seems to be broken. You can find screenshots of drawpix >>> and >>> teapot in the attachments. Any idea? >>> >> >> Looks like only the first row of texels is being uploaded. >> >> Maybe stride is being set to zero in the transfer creation, or similar? > > Hmm, yes - u_default_get_transfer doesn't fill stride in, which is > fine for buffers but busted for textures. I'll modify the two places > where this is being used for textures. > > Keith > OK, I've pushed something which should fix this. Anything more we can resolve on master. Keith -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Sat, Apr 10, 2010 at 12:36 PM, Keith Whitwell wrote: > On Sat, Apr 10, 2010 at 6:59 AM, Chia-I Wu wrote: >> On Fri, Apr 9, 2010 at 9:07 PM, Keith Whitwell wrote: >>> On Fri, 2010-04-09 at 03:43 -0700, Keith Whitwell wrote: On Thu, 2010-04-08 at 15:20 -0700, Marek Olšák wrote: > On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell > wrote: > > OK, it seems like quite a few cases had migrated to the new > > buffer_map_range() behaviour. I've looked at all I can find > and moved > them back to the old behaviour. > > glean is passing now on softpipe. > > There's now an assertion failure in pipe_buffer_flush_mapped_range. > Given a mapped range, the current behavior in debug build doesn't > allow to flush its subrange if it doesn't touch the last byte of the > range. The attached patch fixes that and changes u_uploadmgr for the > mapped and flushed ranges to match. Please review. > > Other than that, it's stable as master. Thank you very much. OK, if nobody chimes in, let's look at merging this to master in the next day or so. >>> >>> I've made a final merge of master into gallium-resources. Please try it >>> out and report/fix any issues. This will be merged tomorrow. >> Texturing in i915g seems to be broken. You can find screenshots of drawpix >> and >> teapot in the attachments. Any idea? >> > > Looks like only the first row of texels is being uploaded. > > Maybe stride is being set to zero in the transfer creation, or similar? Hmm, yes - u_default_get_transfer doesn't fill stride in, which is fine for buffers but busted for textures. I'll modify the two places where this is being used for textures. Keith -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Sat, Apr 10, 2010 at 6:59 AM, Chia-I Wu wrote: > On Fri, Apr 9, 2010 at 9:07 PM, Keith Whitwell wrote: >> On Fri, 2010-04-09 at 03:43 -0700, Keith Whitwell wrote: >>> On Thu, 2010-04-08 at 15:20 -0700, Marek Olšák wrote: >>> > On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell >>> > wrote: >>> > >>> > OK, it seems like quite a few cases had migrated to the new >>> > >>> > buffer_map_range() behaviour. I've looked at all I can find >>> > and moved >>> > them back to the old behaviour. >>> > >>> > glean is passing now on softpipe. >>> > >>> > There's now an assertion failure in pipe_buffer_flush_mapped_range. >>> > Given a mapped range, the current behavior in debug build doesn't >>> > allow to flush its subrange if it doesn't touch the last byte of the >>> > range. The attached patch fixes that and changes u_uploadmgr for the >>> > mapped and flushed ranges to match. Please review. >>> > >>> > Other than that, it's stable as master. Thank you very much. >>> >>> OK, if nobody chimes in, let's look at merging this to master in the >>> next day or so. >>> >> >> I've made a final merge of master into gallium-resources. Please try it >> out and report/fix any issues. This will be merged tomorrow. > Texturing in i915g seems to be broken. You can find screenshots of drawpix > and > teapot in the attachments. Any idea? > Looks like only the first row of texels is being uploaded. Maybe stride is being set to zero in the transfer creation, or similar? Keith -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] to Implement on new GPUs
dear all , Would any one suggest me. How to implement es into new GPU's ? thanking you regards Nitesh Suthar -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
