Bug 83319

Created attachment 105519 [details]
Xorg.0.log-3.16.1-7.g90bc0f1-desktop

Yeah, texturing in geometry shaders hangs. The problem might be that the GS RING constant buffer is bound to slot 16, which isn't a valid constant buffer slot (the last one is 15).

(In reply to comment #2)
> Yeah, texturing in geometry shaders hangs. The problem might be that the GS
> RING constant buffer is bound to slot 16, which isn't a valid constant
> buffer slot (the last one is 15).

Hello Marek!

We're back from vacation, so...;-)

Read about it (R600_MAX_CONST_BUFFERS) in Glenn Kennard <glenn.kennard@gmail.com> patch:
[Mesa-dev] [PATCH] r600g: Implement GL_ARB_sample_shading

Is it that what you mean?
Either way, following the shader dumps.

BTW I have a broken screen shot for geom-outlining-150.png, too if you need.

Created attachment 105548 [details]
gsraytrace-R600_DEBUG-ps-vs.log

Created attachment 105549 [details]
gsraytrace-MESA_GLSL-dump.log

(In reply to comment #3)
> (In reply to comment #2)
> > Yeah, texturing in geometry shaders hangs. The problem might be that the GS
> > RING constant buffer is bound to slot 16, which isn't a valid constant
> > buffer slot (the last one is 15).
> 
> Hello Marek!
> 
> We're back from vacation, so...;-)
> 
> Read about it (R600_MAX_CONST_BUFFERS) in Glenn Kennard
> <glenn.kennard@gmail.com> patch:
> [Mesa-dev] [PATCH] r600g: Implement GL_ARB_sample_shading
> 
> Is it that what you mean?

Yes, but it's just a guess. It may or may not have anything to do with this bug.

Ping!

What's needed?

Ping!

Any news?

Related to Bug 91503 ?

Created attachment 118054 [details]
kmsg: gsraytrace lockup on HD6850

Just noticed the problem today on my HD6850. Unfortunately, it doesn't come back to life all the time. That is either complete lockup (and reboot) or at least Xorg being hung in process state D and gsraytrace in state Z. Attached log produced, when hitting the latter one (though sysrq still worked and terminal after sysrq-r worked well). The lock contains some of the sysrq-show-xyz triggers, which are of help maybe (the blocked cat is from catting one of the radeon sysfs entries). Xorg log only shows event overflows.

GPU hang seems to be 100% reproducable with gsraytrace for me.

Software components being:
media-libs/mesa-9999 (git-4de86e1)
sys-devel/llvm-3.6.2
sys-kernel/vanilla-sources-4.2.0
x11-libs/libdrm-2.4.64

options radeon audio=1 tv=0 dpm=1

(In reply to Heiko from comment #9)
> Created attachment 118054 [details]
> kmsg: gsraytrace lockup on HD6850
> 
> Just noticed the problem today on my HD6850. Unfortunately, it doesn't come
> back to life all the time. That is either complete lockup (and reboot) or at
> least Xorg being hung in process state D and gsraytrace in state Z. Attached
> log produced, when hitting the latter one (though sysrq still worked and
> terminal after sysrq-r worked well). The lock contains some of the
> sysrq-show-xyz triggers, which are of help maybe (the blocked cat is from
> catting one of the radeon sysfs entries). Xorg log only shows event
> overflows.
> 
> GPU hang seems to be 100% reproducable with gsraytrace for me.
> 
> Software components being:
> media-libs/mesa-9999 (git-4de86e1)
> sys-devel/llvm-3.6.2
> sys-kernel/vanilla-sources-4.2.0
> x11-libs/libdrm-2.4.64
> 
> options radeon audio=1 tv=0 dpm=1

Hello Heiko,

I've started this one year ago for _RV730_ (AGP) and it is still open for it.

But as you're on HD6850 and I'm on Turks (6670), now
I've opened up new one for those, here:  bug 91865
I think you should move your logs there.

My impression is that they could be related.

(In reply to Dieter Nützel from comment #3)
> (In reply to comment #2)
> > Yeah, texturing in geometry shaders hangs. The problem might be that the GS
> > RING constant buffer is bound to slot 16, which isn't a valid constant
> > buffer slot (the last one is 15).
> 
> Hello Marek!
> 
> We're back from vacation, so...;-)
> 
> Read about it (R600_MAX_CONST_BUFFERS) in Glenn Kennard
> <glenn.kennard@gmail.com> patch:
> [Mesa-dev] [PATCH] r600g: Implement GL_ARB_sample_shading
> 
> Is it that what you mean?
> Either way, following the shader dumps.
> 
> BTW I have a broken screen shot for geom-outlining-150.png, too if you need.

Broken rendering for 'geom-outlining-150' and
ogl-samples: 'gl-320-primitive-shading'

is FIXED with Mesa-11.0.6 (git, too) on RV730 AGP at least.

'gsraytrace' GPU hang with

RV730 (AGP)

and

NI/Turks XT (6670)

still there.

Try disabling sb for the gs case. Seems to b0rken things...

(In reply to Heiko from comment #13)
> Try disabling sb for the gs case. Seems to b0rken things...

Thanks, Heiko.
I try normally both versions. ;-)
Look here, too: Bug 91865
I have an apitrace, there.

Both lookup.
But with R600_DEBUG=nosb
some seconds (after some broken frames) later.
With sb it lookup immediately.

Update,

this one is NOT solved with current Mesa git.

For EG+ (Bug 91865) this is _fixed_ by 'accident' in Mesa git since:

commit 2239f3eaff5c72c4cb1d4a5be97feb4af3d08d25
Author: Dave Airlie <airlied@redhat.com>
Date:   Mon Nov 30 15:48:22 2015 +1000

    r600/shader: emit tessellation factors to GDS at end of TCS.
    
    When we are finished the shader, we read back all the tess factors
    from LDS and write them to special global memory storage using
    GDS instructions.
    
    This also handles adding NOP when GDS or ENDLOOP end the TCS.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>

Dave and Marek any hints which could point in the right direction?
What is different in this case between R600/R700 and EG+ (NI/Turks in my case) and what should I try next.

I have reported probably a duplicate: https://bugs.freedesktop.org/show_bug.cgi?id=93706
It has also an apitrace trace. If confirmed, i will mark it as a duplicate

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/525.