search for: test_input_glob

...n 02/22/2016 12:26 PM, Hans de Goede wrote: <snip> >> So back to the problem of getting OpenCL(ish) code to work again with >> the recent mesa changes. For starters I would like to get: >> >> src/gallium/tests/trivial/compute.c and then the test with mask 8, >> test_input_global() to work again, when that is working I should be >> able to adjust my llvm work (and if necessary clover) to start to >> work again. >> >> Currently the test_input_global() test uses the following bit of >> TGSI code: >> >> COMP >> DCL SV[0], THREA...

...;snip> >> >>>> So back to the problem of getting OpenCL(ish) code to work again with >>>> the recent mesa changes. For starters I would like to get: >>>> >>>> src/gallium/tests/trivial/compute.c and then the test with mask 8, >>>> test_input_global() to work again, when that is working I should be >>>> able to adjust my llvm work (and if necessary clover) to start to >>>> work again. >>>> >>>> Currently the test_input_global() test uses the following bit of >>>> TGSI code: >>...

...ede wrote: > > <snip> > >>> So back to the problem of getting OpenCL(ish) code to work again with >>> the recent mesa changes. For starters I would like to get: >>> >>> src/gallium/tests/trivial/compute.c and then the test with mask 8, >>> test_input_global() to work again, when that is working I should be >>> able to adjust my llvm work (and if necessary clover) to start to >>> work again. >>> >>> Currently the test_input_global() test uses the following bit of >>> TGSI code: >>> >>> CO...

...his would have to be > discussed and approved by the other gallium/tgsi stakeholders. Understood. So back to the problem of getting OpenCL(ish) code to work again with the recent mesa changes. For starters I would like to get: src/gallium/tests/trivial/compute.c and then the test with mask 8, test_input_global() to work again, when that is working I should be able to adjust my llvm work (and if necessary clover) to start to work again. Currently the test_input_global() test uses the following bit of TGSI code: COMP DCL SV[0], THREAD_ID[0] DCL TEMP[0], LOCAL DCL TEMP[1], LOCAL IMM UINT32 { 8, 0, 0, 0...

...cally, the compute support totally hangs the GPU on my GK208 (NV108), and a reboot is needed. > > Please give a shot at this branch : > http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nvf0_compute > > It fixes the initialization of the compute state and allows me to > launch 'test_input_global' (ie. ./compute 8) on my GK208 without > any dmesg fails. That's a good start but more patches are coming. :-) This branch indeed works somewhat better, but things still hang on the test_system_values compute test for me (this is the first test executed I did not try the others). So...

...n 12/04/2015 09:45 AM, Hans de Goede wrote: <snip> >>> Please give a shot at this branch : >>> http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nvf0_compute >>> >>> It fixes the initialization of the compute state and allows me to >>> launch 'test_input_global' (ie. ./compute 8) on my GK208 without >>> any dmesg fails. That's a good start but more patches are coming. :-) >> >> This branch indeed works somewhat better, but things still hang on the >> >> test_system_values compute test for me (this is the first te...

...gt;>>>> So back to the problem of getting OpenCL(ish) code to work again with >>>>> the recent mesa changes. For starters I would like to get: >>>>> >>>>> src/gallium/tests/trivial/compute.c and then the test with mask 8, >>>>> test_input_global() to work again, when that is working I should be >>>>> able to adjust my llvm work (and if necessary clover) to start to >>>>> work again. >>>>> >>>>> Currently the test_input_global() test uses the following bit of >>>>>...

...t; totally hangs the GPU on my GK208 (NV108), and a reboot is needed. >> >> Please give a shot at this branch : >> http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nvf0_compute >> >> It fixes the initialization of the compute state and allows me to >> launch 'test_input_global' (ie. ./compute 8) on my GK208 without >> any dmesg fails. That's a good start but more patches are coming. :-) > > This branch indeed works somewhat better, but things still hang on the > > test_system_values compute test for me (this is the first test executed > I d...

...gt;>>>> So back to the problem of getting OpenCL(ish) code to work again with >>>>> the recent mesa changes. For starters I would like to get: >>>>> >>>>> src/gallium/tests/trivial/compute.c and then the test with mask 8, >>>>> test_input_global() to work again, when that is working I should be >>>>> able to adjust my llvm work (and if necessary clover) to start to >>>>> work again. >>>>> >>>>> Currently the test_input_global() test uses the following bit of >>>>>...

...nd approved by the other gallium/tgsi stakeholders. > > Understood. > > So back to the problem of getting OpenCL(ish) code to work again with > the recent mesa changes. For starters I would like to get: > > src/gallium/tests/trivial/compute.c and then the test with mask 8, > test_input_global() to work again, when that is working I should be > able to adjust my llvm work (and if necessary clover) to start to > work again. > > Currently the test_input_global() test uses the following bit of > TGSI code: > > COMP > DCL SV[0], THREAD_ID[0] > DCL TEMP[0], LOCAL...

On 01-12-15, Samuel Pitoiset wrote: >>> Ok, here is a MMT trace of vectorAdd: >>> >>> https://fedorapeople.org/~jwrdegoede/vectorAdd.log.gz >> >> Hi Hans, >> >> Thanks a lot. > > Well, I didn't know but Martin has a GK208... > I just tested the compute support on his card and ... it works without > any changes. :-)

...t. With those bits added locally, the compute support totally hangs the GPU on my GK208 (NV108), and a reboot is needed. Please give a shot at this branch : http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nvf0_compute It fixes the initialization of the compute state and allows me to launch 'test_input_global' (ie. ./compute 8) on my GK208 without any dmesg fails. That's a good start but more patches are coming. :-) Btw, according to the trace you sent me, you have a GK208b (NV106). Thanks! > > Regards, > > Hans

Hi All, I've been working on translating the tests/trivial/compute.c tests to opencl (for the buffer setup and kernel launch, I'm keeping the compute kernels in tgsi as an intermediate step). I've got the test_input_global() test working, see: https://fedorapeople.org/~jwrdegoede/compute-opencl-tgsi.c Next I wanted to convert the test_system_values() test and there I've gotten stuck. It uses a PIPE_BUFFER which it rw-binds as a resource. Which OpenCL does not allow. The closest thing is a constant parameter i...

...5 */ > > That needs to be LD.E (and your ST's need to be ST.E). You're using a > 32-bit gmem address, but you need to be using a 64-bit one. I believe > the 32-bit ones work on fermi, but afaik not on Kepler. I do not think that is the problem, src/gallium/tests/trivial/compute test_input_global() has: COMP DCL SV[0], THREAD_ID DCL TEMP[0], LOCAL DCL TEMP[1], LOCAL IMM[0] UINT32 {8, 0, 0, 0} 0: BGNSUB :0 1: UMUL TEMP[0], SV[0], IMM[0] 2: LOAD TEMP[1].xy, RES[32764], TEMP[0] 3: LOAD TEMP[0].x, RES[32767], TEMP[1].yyyy 4: UADD TEMP[1].x, TEMP[0], -TEMP[1] 5: ST...

I believe that your problem is this: /*01a0*/ LD R8, [R8]; /* 0x8000000000821c85 */ That needs to be LD.E (and your ST's need to be ST.E). You're using a 32-bit gmem address, but you need to be using a 64-bit one. I believe the 32-bit ones work on fermi, but afaik not on Kepler. Cheers, -ilia On Wed, Dec 16, 2015 at 12:06 PM, Hans de Goede

Hi, On 18-02-16 17:39, Ilia Mirkin wrote: > On Thu, Feb 18, 2016 at 9:45 AM, Hans de Goede <hdegoede at redhat.com> wrote: >> But this does not seem to be hooked up yet for nouveau. > > Samuel has patches. See > https://cgit.freedesktop.org/~hakzsam/mesa/log/?h=arb_compute_shader_v3 Cool, I will take a look at those. >> So some questions: >> -The commit by

...e.c, > with a recent mesa master, but that does not work either. > > I get the following when I try to run this: > > compute: nvc0/nvc0_resource.c:41: nvc0_surface_create: Assertion > `pres->target != PIPE_BUFFER' failed. Unfortunately, that's expected. :-) IIRC, only test_input_global (ie. ./compute 8) works on Tesla/Fermi, but some other tests work on Kepler (< GK110). > > (gdb) bt > #0 0x00007ffff6cbca98 in raise () from /lib64/libc.so.6 > #1 0x00007ffff6cbe69a in abort () from /lib64/libc.so.6 > #2 0x00007ffff6cb5227 in __assert_fail_base () from /lib...

...ted 0x1/0.000000 (1, 1)[0]: got 0x10/0.000000, expected 0x1/0.000000 (2, 1)[0]: got 0x11/0.000000, expected 0x1/0.000000 (3, 1)[0]: got 0x12/0.000000, expected 0x1/0.000000 (4, 1)[0]: got 0x13/0.000000, expected 0x1/0.000000 (5, 1)[0]: got 0x14/0.000000, expected 0x1/0.000000 (15, 12): FAIL (179) - test_input_global (8, 1): OK (8, 1): OK (8, 1): OK (8, 1): OK - test_private ERROR: SUSTx not yet supported on < nve4 (0, 0)[0]: got 0xdeadbeef/-6259853398707798016.000000, expected 0x0/0.000000 (1, 0)[0]: got 0xdeadbeef/-6259853398707798016.000000, expected 0x1/0.000000 (2, 0)[0]: got 0xdeadbeef/-6259853398707...

...d 0x1/0.000000 >> (2, 1)[0]: got 0x11/0.000000, expected 0x1/0.000000 >> (3, 1)[0]: got 0x12/0.000000, expected 0x1/0.000000 >> (4, 1)[0]: got 0x13/0.000000, expected 0x1/0.000000 >> (5, 1)[0]: got 0x14/0.000000, expected 0x1/0.000000 >> (15, 12): FAIL (179) >> - test_input_global >> (8, 1): OK >> (8, 1): OK >> (8, 1): OK >> (8, 1): OK >> - test_private >> ERROR: SUSTx not yet supported on < nve4 >> (0, 0)[0]: got 0xdeadbeef/-6259853398707798016.000000, expected >> 0x0/0.000000 >> (1, 0)[0]: got 0xdeadbeef/-625985339...

...t 0x10/0.000000, expected 0x1/0.000000 > (2, 1)[0]: got 0x11/0.000000, expected 0x1/0.000000 > (3, 1)[0]: got 0x12/0.000000, expected 0x1/0.000000 > (4, 1)[0]: got 0x13/0.000000, expected 0x1/0.000000 > (5, 1)[0]: got 0x14/0.000000, expected 0x1/0.000000 > (15, 12): FAIL (179) > - test_input_global > (8, 1): OK > (8, 1): OK > (8, 1): OK > (8, 1): OK > - test_private > ERROR: SUSTx not yet supported on < nve4 > (0, 0)[0]: got 0xdeadbeef/-6259853398707798016.000000, expected > 0x0/0.000000 > (1, 0)[0]: got 0xdeadbeef/-6259853398707798016.000000, expected > 0x1...