Bug 1057

Summary:	Windows [8.1] and Intel i7-4770T CPU / HD Graphics 4600 - CLProgramTest.builderTest Freezes
Product:	[JogAmp] Jocl	Reporter:	Sven Gothel <sgothel>
Component:	opencl	Assignee:	Sven Gothel <sgothel>
Status:	CONFIRMED ---
Severity:	major	CC:	wwalker3
Priority:	P2
Version:	1
Hardware:	pc_x86_64
OS:	windows
Type:	---	SCM Refs:	426f3663822cb85c9014ca87affc66181acd0fe8
Workaround:	---
Attachments:	CLProgramTest Win8.1 intelhd jstack trace CLProgramTest win8intelhd 02 jstack

Description Sven Gothel 2014-09-01 13:35:11 CEST

I switched the windows7-x86_64-amd node temporary w/ an
Windows8 IntelHD machine.
All tests passed from all modules, but JOCL.
One test on JOCL failed, i.e. froze the machine.

https://jogamp.org/chuck/view/fwd/job/jocl/label=win7-x86_64-amd/1001/testReport/

Frozen: com.jogamp.opencl.CLProgramTest.builderTest
Platform: WINDOWS / Windows 8.1 6.3 (6.3.0), amd64 (arch), GENERIC_ABI, 8 cores
Froze on 32bit and 64bit tests.

GL_RENDERER Intel(R) HD Graphics 4600
GL_VERSION 4.2.0 - Build 10.18.10.3621

CL_DEVICE_NAME: Intel(R) Core(TM) i7-4770T CPU @ 2.50GHz
CL_DEVICE_VERSION: OpenCL 1.2 (Build 76413)

CL_DEVICE_NAME: Intel(R) HD Graphics 4600
CL_DEVICE_VERSION: OpenCL 1.2

Comment 1 Sven Gothel 2014-09-01 13:46:49 CEST

Created attachment 628 [details]
CLProgramTest Win8.1 intelhd jstack trace

Comment 2 Sven Gothel 2014-09-01 13:55:20 CEST

Updating driver: 15.33.22 ..

Comment 3 Sven Gothel 2014-09-01 14:20:03 CEST

Installed 15.36.0.3652 (beta) - however
driver info shows 10.18.10.3652

I assume only the last number reflects the driver,
i.e. 3621 -> 3652 ?

However, freeze still occurs.

Comment 4 Sven Gothel 2014-09-01 15:48:41 CEST

426f3663822cb85c9014ca87affc66181acd0fe8
    - Properly enforce test order (alphanumeric)    
    - Split builderTest() to synchronized and async tests

Test freezes now already at:

"main" prio=6 tid=0x0000000002510800 nid=0x850 runnable [0x000000000250d000]
   java.lang.Thread.State: RUNNABLE
        at com.jogamp.opencl.llb.impl.CLImpl.clBuildProgram0(Native Method)
        at com.jogamp.opencl.llb.impl.CLImpl.clBuildProgram(CLImpl.java:148)
        at com.jogamp.opencl.CLProgram.build(CLProgram.java:382)
        at com.jogamp.opencl.CLProgram.build(CLProgram.java:230)
        at com.jogamp.opencl.CLProgramTest.test02RebuildProgram(CLProgramTest.java:106)

See Attachment 629 [details]

Comment 5 Sven Gothel 2014-09-01 15:49:10 CEST

Created attachment 629 [details]
CLProgramTest win8intelhd 02 jstack

Comment 6 Sven Gothel 2014-09-01 15:54:46 CEST

(In reply to comment #4)
> 426f3663822cb85c9014ca87affc66181acd0fe8
>     - Properly enforce test order (alphanumeric)    
>     - Split builderTest() to synchronized and async tests
> 
> Test freezes now already at:
> 
> "main" prio=6 tid=0x0000000002510800 nid=0x850 runnable [0x000000000250d000]
>    java.lang.Thread.State: RUNNABLE
>         at com.jogamp.opencl.llb.impl.CLImpl.clBuildProgram0(Native Method)
>         at com.jogamp.opencl.llb.impl.CLImpl.clBuildProgram(CLImpl.java:148)
>         at com.jogamp.opencl.CLProgram.build(CLProgram.java:382)
>         at com.jogamp.opencl.CLProgram.build(CLProgram.java:230)
>         at
> com.jogamp.opencl.CLProgramTest.test02RebuildProgram(CLProgramTest.java:106)
> 
> See Attachment 629 [details]

i.e. the rebuild failed -> freeze in native method!

Comment 7 Sven Gothel 2014-09-01 15:57:29 CEST

(In reply to comment #1)
> Created attachment 628 [details]
> CLProgramTest Win8.1 intelhd jstack trace

Original freeze ^^ 
	at java.util.concurrent.CountDownLatch.await(Unknown Source)
	at com.jogamp.opencl.CLProgramTest.builderTest(CLProgramTest.java:248)

could be caused by having the callback method issued 
on a different thread, i.e. buildLock.unlock(); issued from a thread
other that buildLock.lock():
            callback = new BuildProgramCallback() {
                @Override
                public void buildFinished(final long cl_program) {
                    buildLock.unlock();
                    ...

Comment 8 Wade Walker 2014-09-01 20:34:08 CEST

Is there any way I can help with this? It appears that the Win 8.1 Intel graphics machine is not in the cluster, and even if it was, it would be difficult for me to try potential fixes since the bug freezes the machine :)

I can work on the other remaining bugs though, and maybe the fix for one of those will fix this issue too.

Comment 9 Sven Gothel 2014-09-01 21:12:14 CEST

(In reply to comment #8)
> Is there any way I can help with this? It appears that the Win 8.1 Intel
> graphics machine is not in the cluster, and even if it was, it would be
> difficult for me to try potential fixes since the bug freezes the machine :)
> 
> I can work on the other remaining bugs though, and maybe the fix for one of
> those will fix this issue too.

The 'wrong thread' issue might be generic, 
i.e. no guarantee things get notified on the same thread.
This is similar to GL debug message callbacks, 
but in JOGL we don't need to use locks.

Hence we could use a dedicated callback thread similar to our NEWT EDT,
i.e. CDT (Callback Dispatch Thread) dequeuing and invoking callbacks 
as delivered via the native method - using a ringbuffer.

Since you have no machine, and it's indeed difficult to do this remote,
I agree .. the other bugs might be more reasonable then.