Bug 1057 - Windows [8.1] and Intel i7-4770T CPU / HD Graphics 4600 - CLProgramTest.builderTest Freezes
Summary: Windows [8.1] and Intel i7-4770T CPU / HD Graphics 4600 - CLProgramTest.build...
Status: CONFIRMED
Alias: None
Product: Jocl
Classification: JogAmp
Component: opencl (show other bugs)
Version: 1
Hardware: pc_x86_64 windows
: P2 major
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2014-09-01 13:35 CEST by Sven Gothel
Modified: 2014-09-01 21:12 CEST (History)
1 user (show)

See Also:
Type: ---
SCM Refs:
426f3663822cb85c9014ca87affc66181acd0fe8
Workaround: ---

Attachments
CLProgramTest Win8.1 intelhd jstack trace (7.03 KB, text/plain)
2014-09-01 13:46 CEST, Sven Gothel 		Details
CLProgramTest win8intelhd 02 jstack (6.73 KB, text/plain)
2014-09-01 15:49 CEST, Sven Gothel 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.