Menu
▾
▴
mesa3d-dev
|
From: Roland S. <sr...@vm...> - 2010-04-02 14:17:19
|
I'm planning on merging the gallium-resources branch shortly (after easter). Due to the amount of code changed, it wouldn't be unexpected if some drivers break here and there. So it would be nice if the respective driver authors could take a look at that branch now. If you've missed the discussion about this branch and what this is about, here it is: http://www.mail-archive.com/mes...@li.../msg12726.html I've also removed the video interfaces completely, as they weren't ported to the interface changes and actually some of the video code missed some earlier interface changes so didn't build anyway. Video related work should be done on pipe-video branch which had newer stuff (for video) already. Roland |
|
From: Luca B. <luc...@gm...> - 2010-04-02 15:18:33
|
How about merging gallium-buffer-usage-cleanup as well, which is based on gallium-resources? Unless, it changed recently, the gallium-resources branch left a mix of old PIPE_BUFFER_USAGE_* and new PIPE_TRANSFER_* flags. It would nice to convert drivers having both branches, so that it is done once. However, note that I may be misunderstanding the branches, correct me if I'm worng. |
|
From: Roland S. <sr...@vm...> - 2010-04-02 16:23:05
|
On 02.04.2010 17:18, Luca Barbieri wrote: > How about merging gallium-buffer-usage-cleanup as well, which is based > on gallium-resources? > Unless, it changed recently, the gallium-resources branch left a mix > of old PIPE_BUFFER_USAGE_* and new PIPE_TRANSFER_* flags. > > It would nice to convert drivers having both branches, so that it is done once. > However, note that I may be misunderstanding the branches, correct me > if I'm worng. Yes, I've already merged gallium-buffer-usage-cleanup back into gallium-resources, so this is already done. Roland |
|
From: Marek O. <ma...@gm...> - 2010-04-03 06:23:13
|
There's something fishy in u_upload_mgr, could you please review the first two patches here? http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources With this, r300g works again. -Marek On Fri, Apr 2, 2010 at 4:17 PM, Roland Scheidegger <sr...@vm...>wrote: > I'm planning on merging the gallium-resources branch shortly (after > easter). Due to the amount of code changed, it wouldn't be unexpected if > some drivers break here and there. So it would be nice if the respective > driver authors could take a look at that branch now. > > If you've missed the discussion about this branch and what this is > about, here it is: > > http://www.mail-archive.com/mes...@li.../msg12726.html > > I've also removed the video interfaces completely, as they weren't > ported to the interface changes and actually some of the video code > missed some earlier interface changes so didn't build anyway. Video > related work should be done on pipe-video branch which had newer stuff > (for video) already. > > > 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 > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > |
|
From: Keith W. <ke...@vm...> - 2010-04-06 10:28:36
|
On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote: > There's something fishy in u_upload_mgr, could you please review the > first two patches here? > http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources > > With this, r300g works again. Hmm, I think the second of the patches (flush range relative to mapped range vs whole buffer) may be addressing a regression that has creeped into the -resources branch regarding this behaviour - ie. I think the code you modified was actually correct, but that pipe_flush_mapped_buffer_range() has changed to do the wrong thing. I'll try and figure out what should be happening. Keith |
|
From: Keith W. <kei...@go...> - 2010-04-10 11:36:27
|
On Sat, Apr 10, 2010 at 6:59 AM, Chia-I Wu <ol...@gm...> wrote: > On Fri, Apr 9, 2010 at 9:07 PM, Keith Whitwell <ke...@vm...> 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 <ke...@vm...> >>> > 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 |
|
From: Keith W. <ke...@vm...> - 2010-04-07 17:01:55
|
On Tue, 2010-04-06 at 03:28 -0700, Keith Whitwell wrote: > On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote: > > There's something fishy in u_upload_mgr, could you please review the > > first two patches here? > > http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources > > > > With this, r300g works again. > > Hmm, I think the second of the patches (flush range relative to mapped > range vs whole buffer) may be addressing a regression that has creeped > into the -resources branch regarding this behaviour - ie. I think the > code you modified was actually correct, but that > pipe_flush_mapped_buffer_range() has changed to do the wrong thing. > > I'll try and figure out what should be happening. I've pushed a change which hopefully corrects the behaviour of the buffer_range inlines. Can you give it a try? Keith |
|
From: Keith W. <kei...@go...> - 2010-04-10 11:39:18
|
On Sat, Apr 10, 2010 at 12:36 PM, Keith Whitwell <kei...@go...> wrote: > On Sat, Apr 10, 2010 at 6:59 AM, Chia-I Wu <ol...@gm...> wrote: >> On Fri, Apr 9, 2010 at 9:07 PM, Keith Whitwell <ke...@vm...> 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 <ke...@vm...> >>>> > 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 |
|
From: Marek O. <ma...@gm...> - 2010-04-08 01:58:40
|
On Wed, Apr 7, 2010 at 7:01 PM, Keith Whitwell <ke...@vm...> wrote: > On Tue, 2010-04-06 at 03:28 -0700, Keith Whitwell wrote: > > On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote: > > > There's something fishy in u_upload_mgr, could you please review the > > > first two patches here? > > > http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources<http://cgit.freedesktop.org/%7Emareko/mesa/log/?h=gallium-resources> > > > > > > With this, r300g works again. > > > > Hmm, I think the second of the patches (flush range relative to mapped > > range vs whole buffer) may be addressing a regression that has creeped > > into the -resources branch regarding this behaviour - ie. I think the > > code you modified was actually correct, but that > > pipe_flush_mapped_buffer_range() has changed to do the wrong thing. > > > > I'll try and figure out what should be happening. > > I've pushed a change which hopefully corrects the behaviour of the > buffer_range inlines. Can you give it a try? > Now glean/bufferObject fails on softpipe and r300g. I haven't tested other drivers. -Marek |
|
From: Keith W. <ke...@vm...> - 2010-04-08 13:54:18
|
On Wed, 2010-04-07 at 18:58 -0700, Marek Olšák wrote: > On Wed, Apr 7, 2010 at 7:01 PM, Keith Whitwell <ke...@vm...> > wrote: > > On Tue, 2010-04-06 at 03:28 -0700, Keith Whitwell wrote: > > On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote: > > > There's something fishy in u_upload_mgr, could you please > review the > > > first two patches here? > > > > http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources > > > > > > With this, r300g works again. > > > > Hmm, I think the second of the patches (flush range relative > to mapped > > range vs whole buffer) may be addressing a regression that > has creeped > > into the -resources branch regarding this behaviour - ie. I > think the > > code you modified was actually correct, but that > > pipe_flush_mapped_buffer_range() has changed to do the wrong > thing. > > > > I'll try and figure out what should be happening. > > > I've pushed a change which hopefully corrects the behaviour of > the > buffer_range inlines. Can you give it a try? > > Now glean/bufferObject fails on softpipe and r300g. I haven't tested > other drivers. 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. Keith |
|
From: Marek O. <ma...@gm...> - 2010-04-08 22:20:46
|
On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell <ke...@vm...> 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. -Marek |
|
From: Keith W. <kei...@go...> - 2010-04-10 12:00:45
|
Hmm, not sure whether to merge or squash-merge this branch. Any thoughts? Keith |
|
From: Roland S. <sr...@vm...> - 2010-04-10 14:39:45
|
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 |
|
From: Keith W. <ke...@vm...> - 2010-04-09 10:43:18
|
On Thu, 2010-04-08 at 15:20 -0700, Marek Olšák wrote: > On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell <ke...@vm...> > 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. Keith |
|
From: STEVE555 <ste...@ho...> - 2010-04-09 15:29:44
|
Hi all,
I've git branched and got the latest commits from the
gallium-resources branch and also the latest commits from git master.
I did a gmake -B realclean from a prevous compile on my copy of git
master,and did a git checkout gallium-resources to switch to that
branch,and did a ./autogen.sh with the following options:
--prefix=/usr/local --enable-32-bit --enable-xcb --enable-gallium-nouveau
--with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif
--enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon
--with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests
--with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga
--with-max-width=4096 --with-max-height=4096 --enable-debug
I then did a gmake to compile my copy of gallium-resources,but it ended with
error at the end:
dri_st_api.c: In function ‘dri_st_manager_get_egl_image’:
dri_st_api.c:244: warning: implicit declaration of function
‘pipe_texture_reference’
gcc -c -I. -I../../../../../src/gallium/include
-I../../../../../src/gallium/auxiliary -I../../../../../src/gallium/drivers
-I../../../../../include -I../../../../../src/mesa
-I../../../../../src/gallium/state_trackers/dri/common
-I../../../../../src/mesa/drivers/dri/common -I../../../../../src/mesa/main
-I/usr/include/drm -I/usr/include/libdrm -g -O2 -Wall -Wmissing-prototypes
-std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC
-m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
-DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 dri1_helper.c -o
dri1_helper.o
gcc -c -I. -I../../../../../src/gallium/include
-I../../../../../src/gallium/auxiliary -I../../../../../src/gallium/drivers
-I../../../../../include -I../../../../../src/mesa
-I../../../../../src/gallium/state_trackers/dri/common
-I../../../../../src/mesa/drivers/dri/common -I../../../../../src/mesa/main
-I/usr/include/drm -I/usr/include/libdrm -g -O2 -Wall -Wmissing-prototypes
-std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC
-m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
-DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 dri1.c -o dri1.o
gcc -c -I. -I../../../../../src/gallium/include
-I../../../../../src/gallium/auxiliary -I../../../../../src/gallium/drivers
-I../../../../../include -I../../../../../src/mesa
-I../../../../../src/gallium/state_trackers/dri/common
-I../../../../../src/mesa/drivers/dri/common -I../../../../../src/mesa/main
-I/usr/include/drm -I/usr/include/libdrm -g -O2 -Wall -Wmissing-prototypes
-std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC
-m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
-DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 dri2.c -o dri2.o
dri2.c: In function ‘dri2_create_image_from_name’:
dri2.c:393: error: storage size of ‘templ’ isn’t known
dri2.c:398: error: ‘PIPE_TEXTURE_USAGE_RENDER_TARGET’ undeclared (first use
in this function)
dri2.c:398: error: (Each undeclared identifier is reported only once
dri2.c:398: error: for each function it appears in.)
dri2.c:398: error: ‘PIPE_TEXTURE_USAGE_SAMPLER’ undeclared (first use in
this function)
dri2.c:434: error: ‘struct pipe_screen’ has no member named
‘texture_from_handle’
dri2.c:393: warning: unused variable ‘templ’
dri2.c: In function ‘dri2_destroy_image’:
dri2.c:465: warning: implicit declaration of function
‘pipe_texture_reference’
gmake[5]: *** [dri2.o] Error 1
Regards,
STEVE555
--
View this message in context: http://old.nabble.com/gallium-resources-branch-merge-tp28119468p28191257.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.
|
|
From: Roland S. <sr...@vm...> - 2010-04-10 14:49:44
|
On 10.04.2010 16:43, Chia-I Wu wrote: > On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell > <kei...@go...> 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 |
|
From: Keith W. <ke...@vm...> - 2010-04-09 13:07:32
|
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 <ke...@vm...> > > 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. Keith |
|
From: Keith W. <kei...@go...> - 2010-04-10 15:05:31
|
On Sat, Apr 10, 2010 at 3:49 PM, Roland Scheidegger <sr...@vm...> wrote: > On 10.04.2010 16:43, Chia-I Wu wrote: >> On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell >> <kei...@go...> 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 |
|
From: Keith W. <kei...@go...> - 2010-04-10 15:10:55
|
On Sat, Apr 10, 2010 at 4:05 PM, Keith Whitwell <kei...@go...> wrote: > On Sat, Apr 10, 2010 at 3:49 PM, Roland Scheidegger <sr...@vm...> wrote: >> On 10.04.2010 16:43, Chia-I Wu wrote: >>> On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell >>> <kei...@go...> 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 |
|
From: Roland S. <sr...@vm...> - 2010-04-09 16:15:18
|
On 09.04.2010 17:29, STEVE555 wrote: > Hi all, > I've git branched and got the latest commits from the > gallium-resources branch and also the latest commits from git master. > > I did a gmake -B realclean from a prevous compile on my copy of git > master,and did a git checkout gallium-resources to switch to that > branch,and did a ./autogen.sh with the following options: > > --prefix=/usr/local --enable-32-bit --enable-xcb --enable-gallium-nouveau > --with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif > --enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon > --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests > --with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga > --with-max-width=4096 --with-max-height=4096 --enable-debug > > I then did a gmake to compile my copy of gallium-resources,but it ended with > error at the end: This should be fixed now. Roland |
|
From: STEVE555 <ste...@ho...> - 2010-04-09 17:08:08
|
Dear Roland,
I like to thank you very much for the fixes.I have
compiled from commit 927cec79cedb457efa9e6f335727cfcb8e4908e2 on the
gallium-resources branch and that compiles fine now.
I also did a git merge of my copy of mesa master (from commit
75b8c4a8f869f63991c774caa7e1cec7e988c5ec) into my copy of gallium-resources
from commit 927cec79cedb457efa9e6f335727cfcb8e4908e2 .I'm glad to say that
the merge of my two copies and compile of gallium-resources all went fine.
Regards,
STEVE555
Roland Scheidegger-4 wrote:
>
> On 09.04.2010 17:29, STEVE555 wrote:
>> Hi all,
>> I've git branched and got the latest commits from the
>> gallium-resources branch and also the latest commits from git master.
>>
>> I did a gmake -B realclean from a prevous compile on my copy of git
>> master,and did a git checkout gallium-resources to switch to that
>> branch,and did a ./autogen.sh with the following options:
>>
>> --prefix=/usr/local --enable-32-bit --enable-xcb
>> --enable-gallium-nouveau
>> --with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif
>> --enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon
>> --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests
>> --with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga
>> --with-max-width=4096 --with-max-height=4096 --enable-debug
>>
>> I then did a gmake to compile my copy of gallium-resources,but it ended
>> with
>> error at the end:
> This should be fixed now.
>
> 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
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>
--
View this message in context: http://old.nabble.com/gallium-resources-branch-merge-tp28119468p28195020.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.
|
|
From: Chia-I Wu <ol...@gm...> - 2010-04-09 17:40:18
|
On Sat, Apr 10, 2010 at 12:15 AM, Roland Scheidegger <sr...@vm...> wrote:
> On 09.04.2010 17:29, STEVE555 wrote:
>> Hi all,
>> I've git branched and got the latest commits from the
>> gallium-resources branch and also the latest commits from git master.
>>
>> I did a gmake -B realclean from a prevous compile on my copy of git
>> master,and did a git checkout gallium-resources to switch to that
>> branch,and did a ./autogen.sh with the following options:
>>
>> --prefix=/usr/local --enable-32-bit --enable-xcb --enable-gallium-nouveau
>> --with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif
>> --enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon
>> --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests
>> --with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga
>> --with-max-width=4096 --with-max-height=4096 --enable-debug
>>
>> I then did a gmake to compile my copy of gallium-resources,but it ended with
>> error at the end:
> This should be fixed now.
Thanks for the quick fix. My usual build with st/{egl,glx,dri,vega,es}
also compiles fine on this branch.
--
ol...@Lu...
|
|
From: Chia-I Wu <ol...@gm...> - 2010-04-10 05:59:15
Attachments:
demos-teapot.png
demos-drawpix.png
|
On Fri, Apr 9, 2010 at 9:07 PM, Keith Whitwell <ke...@vm...> 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 <ke...@vm...> >> > 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? -- ol...@Lu... |
|
From: Keith W. <kei...@go...> - 2010-04-10 11:50:28
|
On Sat, Apr 10, 2010 at 12:39 PM, Keith Whitwell <kei...@go...> wrote: > On Sat, Apr 10, 2010 at 12:36 PM, Keith Whitwell > <kei...@go...> wrote: >> On Sat, Apr 10, 2010 at 6:59 AM, Chia-I Wu <ol...@gm...> wrote: >>> On Fri, Apr 9, 2010 at 9:07 PM, Keith Whitwell <ke...@vm...> 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 <ke...@vm...> >>>>> > 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 |
|
From: Chia-I Wu <ol...@gm...> - 2010-04-10 14:43:33
|
On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell <kei...@go...> 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? -- ol...@Lu... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X