https://bugs.freedesktop.org/show_bug.cgi?id=47375
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #47 from Brian Paul 2012-07-27 21:59:45
UTC ---
OK, I'm closing this bug. These 3 commits fix the assertion and performance
issue:
906febaf8bd37fffa4fc14c56eda1dd6e4b4dcda
38184dcd54e77c8f9adc89d337a97afd630b2c07
0e893b42610a2e8f27
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #46 from Barto 2012-07-27 20:24:42 PDT
---
(In reply to comment #45)
> (In reply to comment #44)
> Anyway, I think we can close out this particular bug if the above-mentioned
> patches look OK to everyone.
for me it's Ok with your
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #45 from Brian Paul 2012-07-27 15:12:02
PDT ---
(In reply to comment #44)
> (In reply to comment #43)
> > > Also fog fallback shouldn't apply to depth/stencil buffer drawing neither
> > > (but
> > > OTOH enabled texturing should cau
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #44 from Roland Scheidegger 2012-07-27
14:54:22 PDT ---
(In reply to comment #43)
> > Also fog fallback shouldn't apply to depth/stencil buffer drawing neither
> > (but
> > OTOH enabled texturing should cause a fallback for color bu
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #43 from Brian Paul 2012-07-27 14:16:09
PDT ---
(In reply to comment #40)
> I was actually wondering, do we really need the fallback when there's
> PixelTransfer state? Clearly this applies to DrawPixels, but doesn't this also
> appl
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #42 from Barto 2012-07-27 01:40:32 PDT
---
(In reply to comment #40)
>
> --- a/src/mesa/drivers/common/meta.c
> +++ b/src/mesa/drivers/common/meta.c
> @@ -2280,8 +2280,7 @@ _mesa_meta_DrawPixels(struct gl_context *ctx,
> * Det
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #41 from Barto 2012-07-27 01:21:23 PDT
---
(In reply to comment #39)
> Try setting a breakpoint on radeonSpanRenderStart() and get some stack traces
> when gdb stops there. Maybe set the breakpoint after the splash screen/window
> g
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #40 from Roland Scheidegger 2012-07-27
00:24:19 UTC ---
I was actually wondering, do we really need the fallback when there's
PixelTransfer state? Clearly this applies to DrawPixels, but doesn't this also
apply to TexImage() calls he
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #39 from Brian Paul 2012-07-26 23:39:26
PDT ---
Try setting a breakpoint on radeonSpanRenderStart() and get some stack traces
when gdb stops there. Maybe set the breakpoint after the splash screen/window
goes away because it's sure
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #38 from Barto 2012-07-26 22:33:11 PDT
---
(In reply to comment #37)
> Try setting the RADEON_DEBUG env var to "fall". Ex: export RADEON_DEBUG=fall
> then run blender. It should print a message to stdout/err when a software
> fallb
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #37 from Brian Paul 2012-07-26 22:13:28
PDT ---
Try setting the RADEON_DEBUG env var to "fall". Ex: export RADEON_DEBUG=fall
then run blender. It should print a message to stdout/err when a software
fallback is hit. That should g
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #36 from Roland Scheidegger 2012-07-26
21:42:26 PDT ---
(In reply to comment #33)
> Also, IIRC, blender uses GL_SELECT for which is currently always software.
> There is a patch to hw accelerate it, but it never made it into master:
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #35 from Barto 2012-07-26 20:33:26 PDT
---
(In reply to comment #31)
> (In reply to comment #29)
> Unfortunately I think this is expected. Previously swrast didn't map whole
> buffers, only parts of them. For much simpler and more ro
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #34 from Roland Scheidegger 2012-07-26
20:24:37 PDT ---
(In reply to comment #31)
> Unfortunately I think this is expected. Previously swrast didn't map whole
> buffers, only parts of them. For much simpler and more robust code thoug
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #33 from Alex Deucher 2012-07-26 20:22:21 UTC ---
Also, IIRC, blender uses GL_SELECT for which is currently always software.
There is a patch to hw accelerate it, but it never made it into master:
http://cgit.freedesktop.org/mesa/mes
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #32 from Barto 2012-07-26 20:13:04 PDT
---
(In reply to comment #30)
> That'll be a bit more work to diagnose. Have you ever used any profiling
> tools?
>
no, but I can try to learn how to use these tools,
I notice that the fall
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #31 from Roland Scheidegger 2012-07-26
20:10:28 PDT ---
(In reply to comment #29)
> I compiled mesa lib, Blender runs without crash, but it still very slow in the
> GUI ( too much lag when I click in the gui, menus ), it's not norma
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #30 from Brian Paul 2012-07-26 19:56:28
PDT ---
(In reply to comment #29)
> (In reply to comment #28)
> > Can you try making this change to radeon_span.c:
> >
> > diff --git a/src/mesa/drivers/dri/radeon/radeon_span.c
> > b/src/mesa
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #29 from Barto 2012-07-26 19:19:49 PDT
---
(In reply to comment #28)
> Can you try making this change to radeon_span.c:
>
> diff --git a/src/mesa/drivers/dri/radeon/radeon_span.c
> b/src/mesa/drivers/dri/ra
> index 1f2ba49..fd91f88
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #28 from Brian Paul 2012-07-26 18:45:48
PDT ---
Can you try making this change to radeon_span.c:
diff --git a/src/mesa/drivers/dri/radeon/radeon_span.c
b/src/mesa/drivers/dri/ra
index 1f2ba49..fd91f88 100644
--- a/src/mesa/drivers/d
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #27 from Barto 2012-07-26 16:56:50 PDT
---
(In reply to comment #26)
> (In reply to comment #24)
>
> > (gdb) print colorType
> > $3 = 0
> >
> > that's why this assertion fails in line 1326 :
> >
> > GLchan rgbaSave[MAX_WIDTH][4];
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #26 from Brian Paul 2012-07-26 16:45:30
PDT ---
(In reply to comment #24)
> (gdb) print colorType
> $3 = 0
>
> that's why this assertion fails in line 1326 :
>
> GLchan rgbaSave[MAX_WIDTH][4];
> struct swrast_renderbuffer *srb = s
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #25 from Roland Scheidegger 2012-07-26
16:30:37 PDT ---
A very quick look at blender source shows it can indeed use PixelTransfer ops,
in particular scale/bias. Those should be possible to accelerate (both with and
without fragment s
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #24 from Barto 2012-07-26 16:11:31 PDT
---
I have finished the compilation of the debug mesa lib ( with CFLAG=-g )
now the result when gdb stops in breakpoint in meta.c, line 2258 :
(gdb) print ctx->_ImageTransferState
$4 = 1
(gdb
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #23 from Barto 2012-07-26 15:46:16 PDT
---
(In reply to comment #22)
>
> Hmm, if _ImageTransferState==0 and ctx->Fog.Enabled==0 the condition is false
> and we shouldn't be setting fallback=true.
>
> How did you build Mesa? See co
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #22 from Brian Paul 2012-07-26 15:24:00
PDT ---
(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
> >
> > There's a leading underscore on that variable. Did you miss that?
>
> I miss the underscor
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #21 from Barto 2012-07-26 15:12:44 PDT
---
(In reply to comment #20)
> (In reply to comment #19)
>
> There's a leading underscore on that variable. Did you miss that?
I miss the underscore,
after correctin here is the result :
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #20 from Brian Paul 2012-07-26 15:09:14
UTC ---
(In reply to comment #19)
> I use another way and now it works, gdb can reach _mesa_meta_DrawPixels,
>
> for that I set 4 breakpoints in order to reach the line where "fallback =
> GL_
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #19 from Barto 2012-07-26 15:07:37 UTC
---
I use another way and now it works, gdb can reach _mesa_meta_DrawPixels,
for that I set 4 breakpoints in order to reach the line where "fallback =
GL_TRUE" in meta.c file :
break meta.c:22
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #18 from Barto 2012-07-26 14:10:17 PDT
---
(In reply to comment #17)
> According to hartmut's comment #2 earlier, the stack trace says
> _mesa_meta_DrawPixels() was called. Can you verify that? That is, after the
> assertion fails
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #17 from Brian Paul 2012-07-26 13:50:00
PDT ---
(In reply to comment #16)
> (In reply to comment #15)
>
> > Let's first find out why the 'fallback' variable in _mesa_meta_DrawPixels()
> > is
> > getting set. Basically, use gdb to
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #16 from Barto 2012-07-26 12:25:36 PDT
---
(In reply to comment #15)
> Let's first find out why the 'fallback' variable in _mesa_meta_DrawPixels() is
> getting set. Basically, use gdb to set a breakpoint in
> _mesa_meta_DrawPixels
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #15 from Brian Paul 2012-07-25 22:22:58
PDT ---
(In reply to comment #14)
> Brian, can you tell me what are the differences in swrast component between
> the
> 7.11.2-1 mesa release version and the 8.0.x release ?
There's a ton of
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #14 from Barto 2012-07-25 18:56:11 PDT
---
(In reply to comment #13)
> I also tried forcing fallback=1 so that _swrast_DrawPixels() gets called but I
> didn't see any failed assertions. I'm using the Mesa 8.0.x branch.
>
> I don't
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #13 from Brian Paul 2012-07-25 13:53:09
PDT ---
Sorry, I misread your update too quickly and thought that you had added some
assertions. I think we still need to get to the root cause of those before
trying to diagnose performance p
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #12 from Barto 2012-07-24 21:36:18 UTC
---
(In reply to comment #11)
> Adding new assertions shouldn't effect things like that since you're not
> actually changing any values. There must be something else happening.
>
I didn't add
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #11 from Brian Paul 2012-07-24 19:52:06
PDT ---
Adding new assertions shouldn't effect things like that since you're not
actually changing any values. There must be something else happening.
As for the performance, perhaps it's the
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #10 from Barto 2012-07-24 18:51:35 PDT
---
in fact my fix is not good, blender can be launched but everything is slow (
clicks on the interface, significant latency in the GUI ),
so we need to find a true fix for this bug
(In reply
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #9 from Barto 2012-07-24 18:29:47 PDT
---
I found a fix for this bug, but it's a dirty fix :
the solution is to comment some assert() functions in 3 files :
1) in swrast/s_span.c
comment line 1078 :
assert(datatype == GL_FLOAT);
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #8 from Barto 2012-07-24 16:01:22 PDT
---
(In reply to comment #7)
> That looks about right. How exactly did you configure/build Mesa? You make
> need something like "CFLAGS=-g ./configure ..." to make sure you get -g and
> not
>
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #7 from Brian Paul 2012-07-24 15:53:41 PDT
---
That looks about right. How exactly did you configure/build Mesa? You make
need something like "CFLAGS=-g ./configure ..." to make sure you get -g and not
-O2 when building Mesa.
Othe
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #6 from Barto 2012-07-24 15:46:01 PDT
---
(In reply to comment #5)
> You don't need to recompile blender for debugging, only Mesa.
I'm a newbie in gdb, can you tell me how I must proceed in order to debug mesa
and blender ?
I have
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #5 from Brian Paul 2012-07-24 13:36:52 PDT
---
You don't need to recompile blender for debugging, only Mesa.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: --
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #4 from Barto 2012-07-24 10:46:37 UTC
---
(In reply to comment #3)
> (In reply to comment #2)
> > same bug with a radeon 9000 card ( M9 ) :
> >
> > OpenGL renderer string: Mesa DRI R200 (RV250 4C66) x86/MMX/SSE2 TCL DRI2
> >
> > bl
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #3 from Brian Paul 2012-07-19 19:31:37 PDT
---
(In reply to comment #2)
> same bug with a radeon 9000 card ( M9 ) :
>
> OpenGL renderer string: Mesa DRI R200 (RV250 4C66) x86/MMX/SSE2 TCL DRI2
>
> blender crashs with this message w
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #2 from Barto 2012-07-13 10:10:37 PDT
---
same bug with a radeon 9000 card ( M9 ) :
OpenGL renderer string: Mesa DRI R200 (RV250 4C66) x86/MMX/SSE2 TCL DRI2
blender crashs with this message with mesa 8.0.4 :
blender: swrast/s_span
https://bugs.freedesktop.org/show_bug.cgi?id=47375
hart...@technotecture.com changed:
What|Removed |Added
CC||hart...@technotecture.com
---
48 matches
Mail list logo
