[Piglit] [PATCH] draw-range-elements-base-vertex: Require GLSL 1.30.
Signed-off-by: Vinson Lee
---
.../spec/arb_draw_elements_base_vertex/draw-range-elements-base-vertex.c | 1 +
1 file changed, 1 insertion(+)
diff --git
a/tests/spec/arb_draw_elements_base_vertex/draw-range-elements-base-vertex.c
b/tests/spec/arb_draw_elements_base_vertex/draw-range-elements-base-vertex.c
index 0f68e3c..9251374 100644
--- a/tests/spec/arb_draw_elements_base_vertex/draw-range-elements-base-vertex.c
+++ b/tests/spec/arb_draw_elements_base_vertex/draw-range-elements-base-vertex.c
@@ -108,6 +108,7 @@ piglit_init(int argc, char **argv)
if (piglit_get_gl_version() < 32) {
piglit_require_extension("GL_ARB_draw_elements_base_vertex");
+ piglit_require_GLSL_version(130);
}
/* Create program */
--
1.8.3.2
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] framework: Fix resuming of previous runs
I also find that being able to resume tests is also very important. There is never a complete guarantee that a computers driver will be able to run all tests from start to finish. It's really important to be able to test all of the driver from start to finish, but in cases when it suddenly stops it would be good to know this. Also, It may be useful to have include the following when piglit is resumed. 1) resuming of previous time counter. ( Resume always causes a reset of the elapsed time. ) 2) How many times the test is resumed. As Damien said there is often times a case where there is repeated system hangs. 3) whether or not the resume went from threaded or not. Although it would be good if the test just resumed using the previously stored settings. On Fri, Nov 15, 2013 at 11:09 AM, Damien Lespiau wrote: > On Fri, Nov 15, 2013 at 08:51:42AM -0800, Dylan Baker wrote: > > > This looks fine. I had implemented this when I did the status work, > but then > > > didn't think I needed it. Resume is not a commonly used feature > obviously. > > FWIW, it's something we really need working with the i915 test-suite in > intel-gpu-tools. Some tests there are not very gentle and are likely to > cause hard hangs. > > Thanks for the review. > > -- > Damien > ___ > Piglit mailing list > Piglit@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/piglit > ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] cl: Add a test for clEnqueueCopyBuffer
On Fri, Nov 15, 2013 at 04:38:33PM -0600, Aaron Watry wrote:
> On Fri, Nov 15, 2013 at 1:46 PM, Tom Stellard wrote:
> > From: Tom Stellard
> >
> > ---
> > tests/all_cl.tests | 1 +
> > tests/cl/api/CMakeLists.cl.txt | 1 +
> > tests/cl/api/enqueue-copy-buffer.c | 87
> > ++
> > 3 files changed, 89 insertions(+)
> > create mode 100644 tests/cl/api/enqueue-copy-buffer.c
> >
> > diff --git a/tests/all_cl.tests b/tests/all_cl.tests
> > index 877119e..a648e1a 100644
> > --- a/tests/all_cl.tests
> > +++ b/tests/all_cl.tests
> > @@ -59,6 +59,7 @@ add_plain_test(api, 'clRetainComandQueue and
> > clReleaseCommandQueue', ['cl-api-re
> > add_plain_test(api, 'clGetCommandQueueInfo',
> > ['cl-api-get-command-queue-info'])
> > # Memory objects
> > add_plain_test(api, 'clCreateBuffer', ['cl-api-create-buffer'])
> > +add_plain_test(api, 'clEnqueueCopyBuffer', ['cl-api-enqueue-copy-buffer'])
> > add_plain_test(api, 'clEnqueueReadBuffer and clEnqueueWriteBuffer',
> > ['cl-api-enqueue-read_write-buffer'])
> > add_plain_test(api, 'clGetMemObjectInfo', ['cl-api-get-mem-object-info'])
> > add_plain_test(api, 'clGetImageInfo', ['cl-api-get-image-info'])
> > diff --git a/tests/cl/api/CMakeLists.cl.txt b/tests/cl/api/CMakeLists.cl.txt
> > index ae7e3bf..7374b64 100644
> > --- a/tests/cl/api/CMakeLists.cl.txt
> > +++ b/tests/cl/api/CMakeLists.cl.txt
> > @@ -15,6 +15,7 @@ piglit_cl_add_api_test (retain_release-command-queue
> > retain_release-command-queu
> >
> > # Memory objects
> > piglit_cl_add_api_test (create-buffer create-buffer.c)
> > +piglit_cl_add_api_test (enqueue-copy-buffer enqueue-copy-buffer.c)
> > piglit_cl_add_api_test (enqueue-read_write-buffer
> > enqueue-read_write-buffer.c)
> > piglit_cl_add_api_test (retain_release-mem-object
> > retain_release-mem-object.c)
> > piglit_cl_add_api_test (get-mem-object-info get-mem-object-info.c)
> > diff --git a/tests/cl/api/enqueue-copy-buffer.c
> > b/tests/cl/api/enqueue-copy-buffer.c
> > new file mode 100644
> > index 000..34118d6
> > --- /dev/null
> > +++ b/tests/cl/api/enqueue-copy-buffer.c
> > @@ -0,0 +1,87 @@
> > +/*
> > + * Copyright 2013 Advanced Micro Devices, Inc.
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice (including the
> > next
> > + * paragraph) shall be included in all copies or substantial portions of
> > the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> > OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > + * DEALINGS IN THE SOFTWARE.
> > + *
> > + * Authors: Tom Stellard
> > + *
> > + */
> > +
> > +#include "piglit-framework-cl-api.h"
> > +#include "piglit-util-cl.h"
> > +
> > +
> > +PIGLIT_CL_API_TEST_CONFIG_BEGIN
> > +
> > + config.name = "clEnqueueCopyBuffer";
> > + config.version_min = 10;
> > +
> > + config.run_per_platform = true;
> > + config.create_context = true;
> > +
> > +PIGLIT_CL_API_TEST_CONFIG_END
> > +
> > +enum piglit_result
> > +piglit_cl_test(const int argc,
> > + const char **argv,
> > + const struct piglit_cl_api_test_config* config,
> > + const struct piglit_cl_api_test_env* env)
> > +{
> > + int host_src_buffer[4] = {1, 2, 3, 4};
> > + int host_dst_buffer[4] = {0, 0, 0, 0};
> > + cl_mem device_src_buffer, device_dst_buffer;
> > + cl_command_queue queue = env->context->command_queues[0];
> > + cl_int err;
> > + int i;
> > +
> > + memset(host_dst_buffer, 0, sizeof(host_dst_buffer));
>
> Is this necessary given that host_dst_buffer is initialized as {0, 0, 0, 0}?
>
> > +
> > + device_src_buffer = piglit_cl_create_buffer(
> > + env->context, 0,
> > sizeof(host_src_buffer));
> > + device_dst_buffer = piglit_cl_create_buffer(
> > + env->context, 0,
> > sizeof(host_dst_buffer));
>
> For both of these buffers, would you mind explicitly passing the
> cl_mem_flags as CL_MEM_READ_WRITE
> which is the default anyway? Without that, I had
Re: [Piglit] [PATCH 3/6] dmesg: setup dmesg to be able to mark a test warn or fail
On Friday, November 15, 2013 06:04:28 PM Ken Phillis Jr wrote: > On Fri, Nov 15, 2013 at 5:49 PM, Marek Olšák wrote: > > I decided to leave this decision to the user. Of course you should > > expect false negative results with concurrency, but that's acceptable > > for people who want piglit to finish in 15 minutes instead of 60 on > > quad-core. > > > > Marek > > The piglit runtime is always highly dependent on system configuration and > runtime I have personally found that in a single thread that Piglit > finishes in about 20 minutes and when ran in parallel the test takes about > 5 minutes when checking against mesa. Please keep in mind that many of the professional developers have occasions requring them run piglit on machines that are older than dust, and a single threaded runtime can easily go over an hour. signature.asc Description: This is a digitally signed message part. ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH 3/6] dmesg: setup dmesg to be able to mark a test warn or fail
On Fri, Nov 15, 2013 at 5:49 PM, Marek Olšák wrote: > I decided to leave this decision to the user. Of course you should > expect false negative results with concurrency, but that's acceptable > for people who want piglit to finish in 15 minutes instead of 60 on > quad-core. > > Marek > > The piglit runtime is always highly dependent on system configuration and runtime I have personally found that in a single thread that Piglit finishes in about 20 minutes and when ran in parallel the test takes about 5 minutes when checking against mesa. ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] Require Signed-off-by for patches?
On Fri, Nov 15, 2013 at 1:42 PM, Eric Anholt wrote: > Jordan Justen writes: >> Do we think Signed-off-by may cause people to have reservations about >> contributing code to piglit? > > No, but I know from other projects that I *will* forget signed-off-by > and get nagged about it. Paul updated HACKING to say we 'welcome' people to use it. Maybe we just upgrade that to 'requested', and make it the norm for now. It can feedback along with other review comments, but not enough for a respin of a patch on its own. > I think s-o-b is silly. Whoever incorrectly put their s-o-b on a patch > will just say "Oh, I had no idea I was agreeing to *that*", since most > new people I see apply s-o-b at someone's else's request don't know > about the developer's certificate of origin, or don't read it when > pointed to it. It's like a EULA we present to developers, and they just > click right through. True. I think some people wouldn't necessarily bother themselves with the details. But it is much easier to understand than any EULA, and it is pretty clear with Signed-off-by that you are putting your name on the line with regards to the patch. The more projects that do the same thing, the more likely people are to understand what it means. > That said, I'm not super opposed if other people are excited about it. It looks like I'm the only one putting forth positive arguments, and I wouldn't say I'm real concerned about it. So, at this point I would say the nays have it. -Jordan ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH 3/6] dmesg: setup dmesg to be able to mark a test warn or fail
I agree with Marke and took the same approach. In my work-in-progress v2 patches I have added a message in the 'note' field to go along with a dmesg-* status if concurrency is on noting that cocurrency makes dmesg reporting unreliable. On Saturday, November 16, 2013 12:49:41 AM Marek Olšák wrote: > I decided to leave this decision to the user. Of course you should > expect false negative results with concurrency, but that's acceptable > for people who want piglit to finish in 15 minutes instead of 60 on > quad-core. > > Marek > > On Fri, Nov 15, 2013 at 10:51 PM, Ken Phillis Jr wrote: > > I believe it would be a good idea to modify the core behavior of the dmesg > > flag to make sure that it can only be enabled when you are not running in > > concurrent. This is because the wrong test could be flagged as causing the > > dmesg message when it should be another test. This only has to deal with > > the effects of synchronization. > > > > On Fri, Nov 15, 2013 at 12:42 PM, Marek Olšák wrote: > >> Why not to have both? > >> > >> Marek > >> > >> On Fri, Nov 15, 2013 at 7:33 PM, Dylan Baker > >> > >> wrote: > >> > On Friday, November 15, 2013 06:28:41 PM Marek Olšák wrote: > >> >> I'll gladly type --dmesg=radeon. > >> >> > >> >> I have my own script for running piglit anyway, which calls piglit-run > >> >> and piglit-summary-html, and the result and summary directories are > >> >> named $(date)_$(time)_$(GLrenderer)_$(test_filters), and it can do a > >> >> couple of other things. > >> >> > >> >> Marek > >> >> > >> >> On Fri, Nov 15, 2013 at 5:26 PM, Dylan Baker > >> > > >> > wrote: > >> >> > On Friday, November 15, 2013 10:42:11 AM Daniel Vetter wrote: > >> >> >> On Thu, Nov 14, 2013 at 10:35:03AM -0800, Dylan Baker wrote: > >> >> >> > On Thursday, November 14, 2013 05:34:38 PM Daniel Vetter wrote: > >> >> >> > > On Thu, Nov 14, 2013 at 08:04:20AM -0800, Dylan Baker wrote: > >> >> >> > > > On Thursday, November 14, 2013 02:52:41 PM Daniel Vetter > >> >> >> > > > > >> >> >> > > > wrote: > >> >> >> > > > > On Tue, Nov 12, 2013 at 07:54:01AM -0800, Dylan Baker wrote: > >> >> >> > > > > > This gives the dmesg class lists of statuses that will > >> >> >> > > > > > make a > >> >> >> > > > > > test > >> >> >> > > > > > a > >> >> >> > > > > > warn or a fail, it includes a few basic checks, namely > >> >> >> > > > > > i915 > >> >> >> > > > > > errors > >> >> >> > > > > > and > >> >> >> > > > > > that tests have not segfaulted. > >> >> >> > > > > > > >> >> >> > > > > > Signed-off-by: Dylan Baker > >> >> >> > > > > > --- > >> >> >> > > > > > > >> >> >> > > > > > framework/dmesg.py| 36 > >> >> >> > > > > > > >> >> >> > > > > > framework/exectest.py | 22 +++--- > >> >> >> > > > > > 2 files changed, 47 insertions(+), 11 deletions(-) > >> >> >> > > > > > > >> >> >> > > > > > diff --git a/framework/dmesg.py b/framework/dmesg.py > >> >> >> > > > > > index 9a23c14..edbea88 100644 > >> >> >> > > > > > --- a/framework/dmesg.py > >> >> >> > > > > > +++ b/framework/dmesg.py > >> >> >> > > > > > @@ -22,6 +22,7 @@ > >> >> >> > > > > > > >> >> >> > > > > > """ Module implementing classes for reading posix dmesg > >> >> >> > > > > > > >> >> >> > > > > > """ > >> >> >> > > > > > > >> >> >> > > > > > import os > >> >> >> > > > > > > >> >> >> > > > > > +import re > >> >> >> > > > > > > >> >> >> > > > > > import subprocess > >> >> >> > > > > > from threads import synchronized_self > >> >> >> > > > > > > >> >> >> > > > > > @@ -29,8 +30,10 @@ __all__ = ['Dmesg'] > >> >> >> > > > > > > >> >> >> > > > > > # plain text list of statuses to be considered either a > >> >> >> > > > > > > >> >> >> > > > > > warn > >> >> >> > > > > > > >> >> >> > > > > > or a > >> >> >> > > > > > fail, > >> >> >> > > > > > any > >> >> >> > > > > > # statuses not on this list will simply be ignored. > >> >> >> > > > > > > >> >> >> > > > > > -WARN_STATUSES = [] > >> >> >> > > > > > -FAIL_STATUSES = [] > >> >> >> > > > > > +WARN_STATUSES = ['segfault'] > >> >> >> > > > > > +FAIL_STATUSES = ['\[drm:.*\] \*ERROR\*', > >> >> >> > > > > > + '\[drm\] stuck on [a-zA-Z]* ring', > >> >> >> > > > > > + '\[drm\] GPU crash dump saved'] > >> >> >> > > > > > >> >> >> > > > > I think now that we filter out all the info/debug noise > >> >> >> > > > > maybe we > >> >> >> > > > > could > >> >> >> > > > > go > >> >> >> > > > > the other direction and blacklist a few of the remaining > >> >> >> > > > > things > >> >> >> > > > > from > >> >> >> > > > > the > >> >> >> > > > > core kernel we don't care about. E.g. > >> >> >> > > > > > >> >> >> > > > > [ 3867.022895] gem_evict_every (2671) used greatest stack > >> >> >> > > > > depth: > >> >> >> > > > > 2216 > >> >> >> > > > > bytes > >> >> >> > > > > left > >> >> >> > > > > > >> >> >> > > > > is a warn level message, but I don't care one bit about it > >> >> >> > > > > (as > >> >> >> > > > > long > >> >> >>
Re: [Piglit] [PATCH 3/6] dmesg: setup dmesg to be able to mark a test warn or fail
I decided to leave this decision to the user. Of course you should expect false negative results with concurrency, but that's acceptable for people who want piglit to finish in 15 minutes instead of 60 on quad-core. Marek On Fri, Nov 15, 2013 at 10:51 PM, Ken Phillis Jr wrote: > I believe it would be a good idea to modify the core behavior of the dmesg > flag to make sure that it can only be enabled when you are not running in > concurrent. This is because the wrong test could be flagged as causing the > dmesg message when it should be another test. This only has to deal with the > effects of synchronization. > > > On Fri, Nov 15, 2013 at 12:42 PM, Marek Olšák wrote: >> >> Why not to have both? >> >> Marek >> >> On Fri, Nov 15, 2013 at 7:33 PM, Dylan Baker >> wrote: >> > On Friday, November 15, 2013 06:28:41 PM Marek Olšák wrote: >> >> I'll gladly type --dmesg=radeon. >> >> >> >> I have my own script for running piglit anyway, which calls piglit-run >> >> and piglit-summary-html, and the result and summary directories are >> >> named $(date)_$(time)_$(GLrenderer)_$(test_filters), and it can do a >> >> couple of other things. >> >> >> >> Marek >> >> >> >> On Fri, Nov 15, 2013 at 5:26 PM, Dylan Baker >> > wrote: >> >> > On Friday, November 15, 2013 10:42:11 AM Daniel Vetter wrote: >> >> >> On Thu, Nov 14, 2013 at 10:35:03AM -0800, Dylan Baker wrote: >> >> >> > On Thursday, November 14, 2013 05:34:38 PM Daniel Vetter wrote: >> >> >> > > On Thu, Nov 14, 2013 at 08:04:20AM -0800, Dylan Baker wrote: >> >> >> > > > On Thursday, November 14, 2013 02:52:41 PM Daniel Vetter >> >> >> > > > wrote: >> >> >> > > > > On Tue, Nov 12, 2013 at 07:54:01AM -0800, Dylan Baker wrote: >> >> >> > > > > > This gives the dmesg class lists of statuses that will >> >> >> > > > > > make a >> >> >> > > > > > test >> >> >> > > > > > a >> >> >> > > > > > warn or a fail, it includes a few basic checks, namely >> >> >> > > > > > i915 >> >> >> > > > > > errors >> >> >> > > > > > and >> >> >> > > > > > that tests have not segfaulted. >> >> >> > > > > > >> >> >> > > > > > Signed-off-by: Dylan Baker >> >> >> > > > > > --- >> >> >> > > > > > >> >> >> > > > > > framework/dmesg.py| 36 >> >> >> > > > > > >> >> >> > > > > > framework/exectest.py | 22 +++--- >> >> >> > > > > > 2 files changed, 47 insertions(+), 11 deletions(-) >> >> >> > > > > > >> >> >> > > > > > diff --git a/framework/dmesg.py b/framework/dmesg.py >> >> >> > > > > > index 9a23c14..edbea88 100644 >> >> >> > > > > > --- a/framework/dmesg.py >> >> >> > > > > > +++ b/framework/dmesg.py >> >> >> > > > > > @@ -22,6 +22,7 @@ >> >> >> > > > > > >> >> >> > > > > > """ Module implementing classes for reading posix dmesg >> >> >> > > > > > """ >> >> >> > > > > > >> >> >> > > > > > import os >> >> >> > > > > > >> >> >> > > > > > +import re >> >> >> > > > > > >> >> >> > > > > > import subprocess >> >> >> > > > > > from threads import synchronized_self >> >> >> > > > > > >> >> >> > > > > > @@ -29,8 +30,10 @@ __all__ = ['Dmesg'] >> >> >> > > > > > >> >> >> > > > > > # plain text list of statuses to be considered either a >> >> >> > > > > > warn >> >> >> > > > > > or a >> >> >> > > > > > fail, >> >> >> > > > > > any >> >> >> > > > > > # statuses not on this list will simply be ignored. >> >> >> > > > > > >> >> >> > > > > > -WARN_STATUSES = [] >> >> >> > > > > > -FAIL_STATUSES = [] >> >> >> > > > > > +WARN_STATUSES = ['segfault'] >> >> >> > > > > > +FAIL_STATUSES = ['\[drm:.*\] \*ERROR\*', >> >> >> > > > > > + '\[drm\] stuck on [a-zA-Z]* ring', >> >> >> > > > > > + '\[drm\] GPU crash dump saved'] >> >> >> > > > > >> >> >> > > > > I think now that we filter out all the info/debug noise >> >> >> > > > > maybe we >> >> >> > > > > could >> >> >> > > > > go >> >> >> > > > > the other direction and blacklist a few of the remaining >> >> >> > > > > things >> >> >> > > > > from >> >> >> > > > > the >> >> >> > > > > core kernel we don't care about. E.g. >> >> >> > > > > >> >> >> > > > > [ 3867.022895] gem_evict_every (2671) used greatest stack >> >> >> > > > > depth: >> >> >> > > > > 2216 >> >> >> > > > > bytes >> >> >> > > > > left >> >> >> > > > > >> >> >> > > > > is a warn level message, but I don't care one bit about it >> >> >> > > > > (as >> >> >> > > > > long >> >> >> > > > > as >> >> >> > > > > it >> >> >> > > > > doesn't approach 0). But there's other warn level stuff >> >> >> > > > > which is >> >> >> > > > > fairly >> >> >> > > > > interesting. >> >> >> > > > > >> >> >> > > > > Just something to throw out there, I'm not sure what the >> >> >> > > > > best way >> >> >> > > > > would >> >> >> > > > > be >> >> >> > > > > to integrate dmesg reporting for piglit in general. >> >> >> > > > > -Daniel >> >> >> > > > >> >> >> > > > My personal problem with the dmesg code we have now (and with >> >> >> > > > *just* >> >> >> > > > blacklisting) is that I have an alps touchpad, it spams dmesg >> >> >
Re: [Piglit] [PATCH v3 1/2] summary.py: Treat subtests as groups
On Friday, November 15, 2013 11:09:30 PM Damien Lespiau wrote: > On Fri, Nov 15, 2013 at 11:05:49AM -0800, Dylan Baker wrote: > > @#$& -e option. I never should have written it, all I do is break it. > > sigh. :( > Looks like a test suite for the test runner would be a brilliant idea :) > > (not volunteering!) We have one! it's just very limited (it only tests status relationships) and is written in (the terrible, horrible, no good, awful) unittest framework. I'm planning to convert it to something else (tenatively nose) and then expand it. Have a look in framework/tests and at piglit-framework-tests.py signature.asc Description: This is a digitally signed message part. ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH v3 1/2] summary.py: Treat subtests as groups
On Fri, Nov 15, 2013 at 11:05:49AM -0800, Dylan Baker wrote: > @#$& -e option. I never should have written it, all I do is break it. sigh. :( Looks like a test suite for the test runner would be a brilliant idea :) (not volunteering!) -- Damien ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] cl: Add a test for clEnqueueCopyBuffer
On Fri, Nov 15, 2013 at 1:46 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> ---
> tests/all_cl.tests | 1 +
> tests/cl/api/CMakeLists.cl.txt | 1 +
> tests/cl/api/enqueue-copy-buffer.c | 87
> ++
> 3 files changed, 89 insertions(+)
> create mode 100644 tests/cl/api/enqueue-copy-buffer.c
>
> diff --git a/tests/all_cl.tests b/tests/all_cl.tests
> index 877119e..a648e1a 100644
> --- a/tests/all_cl.tests
> +++ b/tests/all_cl.tests
> @@ -59,6 +59,7 @@ add_plain_test(api, 'clRetainComandQueue and
> clReleaseCommandQueue', ['cl-api-re
> add_plain_test(api, 'clGetCommandQueueInfo',
> ['cl-api-get-command-queue-info'])
> # Memory objects
> add_plain_test(api, 'clCreateBuffer', ['cl-api-create-buffer'])
> +add_plain_test(api, 'clEnqueueCopyBuffer', ['cl-api-enqueue-copy-buffer'])
> add_plain_test(api, 'clEnqueueReadBuffer and clEnqueueWriteBuffer',
> ['cl-api-enqueue-read_write-buffer'])
> add_plain_test(api, 'clGetMemObjectInfo', ['cl-api-get-mem-object-info'])
> add_plain_test(api, 'clGetImageInfo', ['cl-api-get-image-info'])
> diff --git a/tests/cl/api/CMakeLists.cl.txt b/tests/cl/api/CMakeLists.cl.txt
> index ae7e3bf..7374b64 100644
> --- a/tests/cl/api/CMakeLists.cl.txt
> +++ b/tests/cl/api/CMakeLists.cl.txt
> @@ -15,6 +15,7 @@ piglit_cl_add_api_test (retain_release-command-queue
> retain_release-command-queu
>
> # Memory objects
> piglit_cl_add_api_test (create-buffer create-buffer.c)
> +piglit_cl_add_api_test (enqueue-copy-buffer enqueue-copy-buffer.c)
> piglit_cl_add_api_test (enqueue-read_write-buffer
> enqueue-read_write-buffer.c)
> piglit_cl_add_api_test (retain_release-mem-object
> retain_release-mem-object.c)
> piglit_cl_add_api_test (get-mem-object-info get-mem-object-info.c)
> diff --git a/tests/cl/api/enqueue-copy-buffer.c
> b/tests/cl/api/enqueue-copy-buffer.c
> new file mode 100644
> index 000..34118d6
> --- /dev/null
> +++ b/tests/cl/api/enqueue-copy-buffer.c
> @@ -0,0 +1,87 @@
> +/*
> + * Copyright 2013 Advanced Micro Devices, Inc.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Authors: Tom Stellard
> + *
> + */
> +
> +#include "piglit-framework-cl-api.h"
> +#include "piglit-util-cl.h"
> +
> +
> +PIGLIT_CL_API_TEST_CONFIG_BEGIN
> +
> + config.name = "clEnqueueCopyBuffer";
> + config.version_min = 10;
> +
> + config.run_per_platform = true;
> + config.create_context = true;
> +
> +PIGLIT_CL_API_TEST_CONFIG_END
> +
> +enum piglit_result
> +piglit_cl_test(const int argc,
> + const char **argv,
> + const struct piglit_cl_api_test_config* config,
> + const struct piglit_cl_api_test_env* env)
> +{
> + int host_src_buffer[4] = {1, 2, 3, 4};
> + int host_dst_buffer[4] = {0, 0, 0, 0};
> + cl_mem device_src_buffer, device_dst_buffer;
> + cl_command_queue queue = env->context->command_queues[0];
> + cl_int err;
> + int i;
> +
> + memset(host_dst_buffer, 0, sizeof(host_dst_buffer));
Is this necessary given that host_dst_buffer is initialized as {0, 0, 0, 0}?
> +
> + device_src_buffer = piglit_cl_create_buffer(
> + env->context, 0,
> sizeof(host_src_buffer));
> + device_dst_buffer = piglit_cl_create_buffer(
> + env->context, 0,
> sizeof(host_dst_buffer));
For both of these buffers, would you mind explicitly passing the
cl_mem_flags as CL_MEM_READ_WRITE
which is the default anyway? Without that, I had to make a round trip
through the piglit util functions and the
spec to figure out what was happening. Since we're not actually
running a kernel at any point, the flags
themselves shouldn't matter here.
I don't feel too strongly about either change, so either way:
Reviewed-by: Aaron Watry
--Aaron
> + if (!pigl
Re: [Piglit] Require Signed-off-by for patches?
On Fri, Nov 15, 2013 at 3:42 PM, Eric Anholt wrote: > Jordan Justen writes: > >> On Thu, Nov 14, 2013 at 3:09 PM, Ian Romanick wrote: >>> On 11/13/2013 05:12 PM, Matt Turner wrote: On Wed, Nov 13, 2013 at 12:06 PM, Jordan Justen wrote: > What are the arguments against just following the kernel's > Signed-off-by practice? What are the arguments for it? >>> >>> Other than habit, there probably aren't any arguments in-favor for >>> piglit. The sorts of things that patch signing is designed protect >>> against really aren't relevant for piglit. The probability of someone >>> distributing piglit (are there any?) being sued because a third party's >>> IP somehow leaked into the project seems infinitesimal, at best. >> >> So, you're saying there is a stronger argument for adding this for >> Mesa? (I agree. :) >> >> I agree to your point that piglit is less likely to have an issue that >> Signed-off-by can help with. But I also think that once a project has >> decides to adopt Reviewed-by, etc, then the extra step of >> Signed-off-by is trivial. At that point it seems there is some (small) >> benefit gained in consistency of process between open source projects. >> >> It also doesn't hurt that git makes Signed-off-by so easy. If I >> actually had to type it out, then I probably would not think it was >> worth it for piglit. :) >> >> Do we think Signed-off-by may cause people to have reservations about >> contributing code to piglit? > > No, but I know from other projects that I *will* forget signed-off-by > and get nagged about it. > > I think s-o-b is silly. Whoever incorrectly put their s-o-b on a patch > will just say "Oh, I had no idea I was agreeing to *that*", since most > new people I see apply s-o-b at someone's else's request don't know > about the developer's certificate of origin, or don't read it when > pointed to it. It's like a EULA we present to developers, and they just > click right through. I'd agree with this. I guarantee that I will probably forget to attach a s-o-b at some point. At that point, we have some ambiguity about the status of the patch and someone's either going to call me out on it, or the piglit history will have yet another patch that's missing this piece. Unless we have some pre-commit hook enforcing this, things will slip through. I can understand that we might want a signed-off-by statement when the patch was originally contributed/written by someone other than oneself, but if I am submitting and committing my own patches without a 3rd party being involved, I see it as an unnecessary hoop to jump through. That being said, I'm just me, and I'm not a copyright lawyer... so yeah. --Aaron > > That said, I'm not super opposed if other people are excited about it. > > ___ > Piglit mailing list > Piglit@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/piglit > ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
[Piglit] [PATCH] Check that uniform block link errors are detected when skipping stages.
In Mesa, as of commit f38ac41, uniform blocks are only validated
between adjacent shader stages. That means that if a program contains
vertex, geometry, and fragment shader stages, and the vertex and
fragment shader stages refer to a uniform block that isn't referred to
by the geometry stage, then some linker checks may not be performed.
Most possible link errors get detected at a later stage of linking,
but I found one case that wasn't; this test exercises that case.
Test is known to fail with Mesa f38ac41.
---
...e-uniform-block-array-size-mismatch.shader_test | 48 ++
1 file changed, 48 insertions(+)
create mode 100644
tests/spec/glsl-1.50/linker/skip-stage-uniform-block-array-size-mismatch.shader_test
diff --git
a/tests/spec/glsl-1.50/linker/skip-stage-uniform-block-array-size-mismatch.shader_test
b/tests/spec/glsl-1.50/linker/skip-stage-uniform-block-array-size-mismatch.shader_test
new file mode 100644
index 000..dd83093
--- /dev/null
+++
b/tests/spec/glsl-1.50/linker/skip-stage-uniform-block-array-size-mismatch.shader_test
@@ -0,0 +1,48 @@
+// From the GLSL 1.50 spec, section 4.3.7 (Interface Blocks):
+//
+// Furthermore, if a matching block is declared as an array, then
+// the array sizes must also match (or follow array matching rules
+// for the interface between a vertex and a geometry shader).
+//
+// In this test, we deliberately create a uniform block array in both
+// the vertex and fragment shaders, using different array sizes. The
+// geometry shader does not access the uniform block array. Then we
+// check that the implementation correctly reported an error.
+
+[require]
+GLSL >= 1.50
+
+[vertex shader]
+uniform Foo {
+ vec4 x;
+} foo[3];
+
+void main()
+{
+ gl_Position = vec4(foo[0].x);
+}
+
+[geometry shader]
+layout(triangles) in;
+layout(triangle_strip, max_vertices=3) out;
+
+void main()
+{
+ for (int i = 0; i < 3; i++) {
+gl_Position = gl_in[i].gl_Position;
+EmitVertex();
+ }
+}
+
+[fragment shader]
+uniform Foo {
+ vec4 x;
+} bar[2];
+
+void main()
+{
+ gl_FragColor = bar[0].x;
+}
+
+[test]
+link error
--
1.8.4.2
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH 3/6] dmesg: setup dmesg to be able to mark a test warn or fail
I believe it would be a good idea to modify the core behavior of the dmesg flag to make sure that it can only be enabled when you are not running in concurrent. This is because the wrong test could be flagged as causing the dmesg message when it should be another test. This only has to deal with the effects of synchronization. On Fri, Nov 15, 2013 at 12:42 PM, Marek Olšák wrote: > Why not to have both? > > Marek > > On Fri, Nov 15, 2013 at 7:33 PM, Dylan Baker > wrote: > > On Friday, November 15, 2013 06:28:41 PM Marek Olšák wrote: > >> I'll gladly type --dmesg=radeon. > >> > >> I have my own script for running piglit anyway, which calls piglit-run > >> and piglit-summary-html, and the result and summary directories are > >> named $(date)_$(time)_$(GLrenderer)_$(test_filters), and it can do a > >> couple of other things. > >> > >> Marek > >> > >> On Fri, Nov 15, 2013 at 5:26 PM, Dylan Baker > > wrote: > >> > On Friday, November 15, 2013 10:42:11 AM Daniel Vetter wrote: > >> >> On Thu, Nov 14, 2013 at 10:35:03AM -0800, Dylan Baker wrote: > >> >> > On Thursday, November 14, 2013 05:34:38 PM Daniel Vetter wrote: > >> >> > > On Thu, Nov 14, 2013 at 08:04:20AM -0800, Dylan Baker wrote: > >> >> > > > On Thursday, November 14, 2013 02:52:41 PM Daniel Vetter wrote: > >> >> > > > > On Tue, Nov 12, 2013 at 07:54:01AM -0800, Dylan Baker wrote: > >> >> > > > > > This gives the dmesg class lists of statuses that will > make a > >> >> > > > > > test > >> >> > > > > > a > >> >> > > > > > warn or a fail, it includes a few basic checks, namely i915 > >> >> > > > > > errors > >> >> > > > > > and > >> >> > > > > > that tests have not segfaulted. > >> >> > > > > > > >> >> > > > > > Signed-off-by: Dylan Baker > >> >> > > > > > --- > >> >> > > > > > > >> >> > > > > > framework/dmesg.py| 36 > >> >> > > > > > > >> >> > > > > > framework/exectest.py | 22 +++--- > >> >> > > > > > 2 files changed, 47 insertions(+), 11 deletions(-) > >> >> > > > > > > >> >> > > > > > diff --git a/framework/dmesg.py b/framework/dmesg.py > >> >> > > > > > index 9a23c14..edbea88 100644 > >> >> > > > > > --- a/framework/dmesg.py > >> >> > > > > > +++ b/framework/dmesg.py > >> >> > > > > > @@ -22,6 +22,7 @@ > >> >> > > > > > > >> >> > > > > > """ Module implementing classes for reading posix dmesg > """ > >> >> > > > > > > >> >> > > > > > import os > >> >> > > > > > > >> >> > > > > > +import re > >> >> > > > > > > >> >> > > > > > import subprocess > >> >> > > > > > from threads import synchronized_self > >> >> > > > > > > >> >> > > > > > @@ -29,8 +30,10 @@ __all__ = ['Dmesg'] > >> >> > > > > > > >> >> > > > > > # plain text list of statuses to be considered either a > warn > >> >> > > > > > or a > >> >> > > > > > fail, > >> >> > > > > > any > >> >> > > > > > # statuses not on this list will simply be ignored. > >> >> > > > > > > >> >> > > > > > -WARN_STATUSES = [] > >> >> > > > > > -FAIL_STATUSES = [] > >> >> > > > > > +WARN_STATUSES = ['segfault'] > >> >> > > > > > +FAIL_STATUSES = ['\[drm:.*\] \*ERROR\*', > >> >> > > > > > + '\[drm\] stuck on [a-zA-Z]* ring', > >> >> > > > > > + '\[drm\] GPU crash dump saved'] > >> >> > > > > > >> >> > > > > I think now that we filter out all the info/debug noise > maybe we > >> >> > > > > could > >> >> > > > > go > >> >> > > > > the other direction and blacklist a few of the remaining > things > >> >> > > > > from > >> >> > > > > the > >> >> > > > > core kernel we don't care about. E.g. > >> >> > > > > > >> >> > > > > [ 3867.022895] gem_evict_every (2671) used greatest stack > depth: > >> >> > > > > 2216 > >> >> > > > > bytes > >> >> > > > > left > >> >> > > > > > >> >> > > > > is a warn level message, but I don't care one bit about it > (as > >> >> > > > > long > >> >> > > > > as > >> >> > > > > it > >> >> > > > > doesn't approach 0). But there's other warn level stuff > which is > >> >> > > > > fairly > >> >> > > > > interesting. > >> >> > > > > > >> >> > > > > Just something to throw out there, I'm not sure what the > best way > >> >> > > > > would > >> >> > > > > be > >> >> > > > > to integrate dmesg reporting for piglit in general. > >> >> > > > > -Daniel > >> >> > > > > >> >> > > > My personal problem with the dmesg code we have now (and with > >> >> > > > *just* > >> >> > > > blacklisting) is that I have an alps touchpad, it spams dmesg > about > >> >> > > > 10 > >> >> > > > times a minute, so I can't use dmesg reporting because of the > >> >> > > > massive > >> >> > > > number of false positives; we could use some combination of > >> >> > > > blacklisting > >> >> > > > and whitelisting however. > >> >> > > > >> >> > > That sounds like we need a piglit cmdline option to supply a > regex to > >> >> > > filter out crap like that ... Or is the alps touchpad driver so > bad > >> >> > > there's not even a regex we could match it all against? > >> >> > > -Daniel > >> >> > > >> >> > My concern is more that tryin
Re: [Piglit] [PATCH v3 1/2] summary.py: Treat subtests as groups
On 11/15/2013 11:05 AM, Dylan Baker wrote: > On Friday, November 15, 2013 10:58:15 AM Kenneth Graunke wrote: >> ValueError: invalid literal for int() with base 10: 'skip' > @#$& -e option. I never should have written it, all I do is break it. sigh. :( Ah, sorry, I should have thought to try without -e. It's a really useful option, though, and I'm glad you added it. I always use -e pass -e skip. Thanks for fixing this and also thanks for your ongoing Piglit framework maintenance. --Ken ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] Require Signed-off-by for patches?
Jordan Justen writes: > On Thu, Nov 14, 2013 at 3:09 PM, Ian Romanick wrote: >> On 11/13/2013 05:12 PM, Matt Turner wrote: >>> On Wed, Nov 13, 2013 at 12:06 PM, Jordan Justen wrote: What are the arguments against just following the kernel's Signed-off-by practice? >>> >>> What are the arguments for it? >> >> Other than habit, there probably aren't any arguments in-favor for >> piglit. The sorts of things that patch signing is designed protect >> against really aren't relevant for piglit. The probability of someone >> distributing piglit (are there any?) being sued because a third party's >> IP somehow leaked into the project seems infinitesimal, at best. > > So, you're saying there is a stronger argument for adding this for > Mesa? (I agree. :) > > I agree to your point that piglit is less likely to have an issue that > Signed-off-by can help with. But I also think that once a project has > decides to adopt Reviewed-by, etc, then the extra step of > Signed-off-by is trivial. At that point it seems there is some (small) > benefit gained in consistency of process between open source projects. > > It also doesn't hurt that git makes Signed-off-by so easy. If I > actually had to type it out, then I probably would not think it was > worth it for piglit. :) > > Do we think Signed-off-by may cause people to have reservations about > contributing code to piglit? No, but I know from other projects that I *will* forget signed-off-by and get nagged about it. I think s-o-b is silly. Whoever incorrectly put their s-o-b on a patch will just say "Oh, I had no idea I was agreeing to *that*", since most new people I see apply s-o-b at someone's else's request don't know about the developer's certificate of origin, or don't read it when pointed to it. It's like a EULA we present to developers, and they just click right through. That said, I'm not super opposed if other people are excited about it. pgpg4Q981UIMC.pgp Description: PGP signature ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
[Piglit] [PATCH] cl: Add a test for clEnqueueCopyBuffer
From: Tom Stellard
---
tests/all_cl.tests | 1 +
tests/cl/api/CMakeLists.cl.txt | 1 +
tests/cl/api/enqueue-copy-buffer.c | 87 ++
3 files changed, 89 insertions(+)
create mode 100644 tests/cl/api/enqueue-copy-buffer.c
diff --git a/tests/all_cl.tests b/tests/all_cl.tests
index 877119e..a648e1a 100644
--- a/tests/all_cl.tests
+++ b/tests/all_cl.tests
@@ -59,6 +59,7 @@ add_plain_test(api, 'clRetainComandQueue and
clReleaseCommandQueue', ['cl-api-re
add_plain_test(api, 'clGetCommandQueueInfo', ['cl-api-get-command-queue-info'])
# Memory objects
add_plain_test(api, 'clCreateBuffer', ['cl-api-create-buffer'])
+add_plain_test(api, 'clEnqueueCopyBuffer', ['cl-api-enqueue-copy-buffer'])
add_plain_test(api, 'clEnqueueReadBuffer and clEnqueueWriteBuffer',
['cl-api-enqueue-read_write-buffer'])
add_plain_test(api, 'clGetMemObjectInfo', ['cl-api-get-mem-object-info'])
add_plain_test(api, 'clGetImageInfo', ['cl-api-get-image-info'])
diff --git a/tests/cl/api/CMakeLists.cl.txt b/tests/cl/api/CMakeLists.cl.txt
index ae7e3bf..7374b64 100644
--- a/tests/cl/api/CMakeLists.cl.txt
+++ b/tests/cl/api/CMakeLists.cl.txt
@@ -15,6 +15,7 @@ piglit_cl_add_api_test (retain_release-command-queue
retain_release-command-queu
# Memory objects
piglit_cl_add_api_test (create-buffer create-buffer.c)
+piglit_cl_add_api_test (enqueue-copy-buffer enqueue-copy-buffer.c)
piglit_cl_add_api_test (enqueue-read_write-buffer enqueue-read_write-buffer.c)
piglit_cl_add_api_test (retain_release-mem-object retain_release-mem-object.c)
piglit_cl_add_api_test (get-mem-object-info get-mem-object-info.c)
diff --git a/tests/cl/api/enqueue-copy-buffer.c
b/tests/cl/api/enqueue-copy-buffer.c
new file mode 100644
index 000..34118d6
--- /dev/null
+++ b/tests/cl/api/enqueue-copy-buffer.c
@@ -0,0 +1,87 @@
+/*
+ * Copyright 2013 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Tom Stellard
+ *
+ */
+
+#include "piglit-framework-cl-api.h"
+#include "piglit-util-cl.h"
+
+
+PIGLIT_CL_API_TEST_CONFIG_BEGIN
+
+ config.name = "clEnqueueCopyBuffer";
+ config.version_min = 10;
+
+ config.run_per_platform = true;
+ config.create_context = true;
+
+PIGLIT_CL_API_TEST_CONFIG_END
+
+enum piglit_result
+piglit_cl_test(const int argc,
+ const char **argv,
+ const struct piglit_cl_api_test_config* config,
+ const struct piglit_cl_api_test_env* env)
+{
+ int host_src_buffer[4] = {1, 2, 3, 4};
+ int host_dst_buffer[4] = {0, 0, 0, 0};
+ cl_mem device_src_buffer, device_dst_buffer;
+ cl_command_queue queue = env->context->command_queues[0];
+ cl_int err;
+ int i;
+
+ memset(host_dst_buffer, 0, sizeof(host_dst_buffer));
+
+ device_src_buffer = piglit_cl_create_buffer(
+ env->context, 0,
sizeof(host_src_buffer));
+ device_dst_buffer = piglit_cl_create_buffer(
+ env->context, 0,
sizeof(host_dst_buffer));
+ if (!piglit_cl_write_whole_buffer(queue,
+ device_src_buffer, host_src_buffer) ||
+ !piglit_cl_write_whole_buffer(queue,
+ device_dst_buffer, host_dst_buffer)) {
+ return PIGLIT_FAIL;
+ }
+
+ err = clEnqueueCopyBuffer(queue, device_src_buffer, device_dst_buffer,
+ 0, 0, sizeof(host_src_buffer), 0, NULL, NULL);
+ if (!piglit_cl_check_error(err, CL_SUCCESS)) {
+ return PIGLIT_FAIL;
+ }
+
+ if (!piglit_cl_read_whole_buffer(queue, device_dst_buffer,
+ host_dst_buffer)) {
+ return PIGLIT_FAIL;
+ }
+
+ for (i = 0; i < sizeof(host_src_buffer) / sizeof(host_src
Re: [Piglit] [PATCH v3 1/2] summary.py: Treat subtests as groups
On Friday, November 15, 2013 06:25:48 PM Damien Lespiau wrote: > On Thu, Nov 14, 2013 at 10:26:08AM -0800, Dylan Baker wrote: > > This patch causes tests with subtests to be treated as a group, rather > > than as a test. This means that the status the test itself stores will > > be overwritten by those in the subtest. > > > > There is one oddity about this to be aware of; a test with subtests that > > crashes or fails before any of the subtests run will report a fraction > > of 0/1 with the appropriate color, even though all of the subtests will > > report Not Run. > > > > v2: - Add subtests to the results file as full tests (the internal view > > > > of the json), without this they will not appear in changes, fixes, > > etc > > > > - Render the background color of Not Run tests correctly in HTML > > - Apply subtest fractions down the stack > > > > v3: - Don't generate a link for Not Run tests in html page > > > > Tested-by: Tom Stellard > > Signed-off-by: Dylan Baker > > This patch regresses the HTML output here. For tests that do run-time > checks and return 77 (skip), they are now marked as "Not Run" instead of > "skip". This also matters because skip had a link to the details and the > output of skipped tests is usally of interest (it has the reason of the > skip) > > Mind fixing this? Since there are now two non-trivial major bugs on this feature I've reverted it and I'll send out patches to the list again when I have it working. sorry guys. signature.asc Description: This is a digitally signed message part. ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH v3 1/2] summary.py: Treat subtests as groups
On Friday, November 15, 2013 10:58:15 AM Kenneth Graunke wrote: > On 11/14/2013 10:26 AM, Dylan Baker wrote: > > This patch causes tests with subtests to be treated as a group, rather > > than as a test. This means that the status the test itself stores will > > be overwritten by those in the subtest. > > > > There is one oddity about this to be aware of; a test with subtests that > > crashes or fails before any of the subtests run will report a fraction > > of 0/1 with the appropriate color, even though all of the subtests will > > report Not Run. > > > > v2: - Add subtests to the results file as full tests (the internal view > > > > of the json), without this they will not appear in changes, fixes, > > etc > > > > - Render the background color of Not Run tests correctly in HTML > > - Apply subtest fractions down the stack > > > > v3: - Don't generate a link for Not Run tests in html page > > > > Tested-by: Tom Stellard > > Signed-off-by: Dylan Baker > > This patch breaks summary generation for me - on the most basic of cases > (piglit-run twice, summary), so I have serious doubts that you actually > tested it. > > If you make last minute changes to your patch, you still need to retest it. > > Here is the traceback: > >> rm -rf summary; ./piglit-summary-html.py -e pass -e skip summary > > results/batch-* > Traceback (most recent call last): > File "./piglit-summary-html.py", line 98, in > main() > File "./piglit-summary-html.py", line 94, in main > output.generate_html(args.summaryDir, args.exclude_details) > File "/home/kwg/Projects/piglit/framework/summary.py", line 477, in > generate_html > exclude=exclude)) > File "/usr/lib64/python2.7/site-packages/mako/template.py", line 412, > in render > return runtime._render(self, self.callable_, args, data) > File "/usr/lib64/python2.7/site-packages/mako/runtime.py", line 766, > in _render > **_kwargs_for_callable(callable_, data)) > File "/usr/lib64/python2.7/site-packages/mako/runtime.py", line 798, > in _render_context > _exec_template(inherit, lclcontext, args=args, kwargs=kwargs) > File "/usr/lib64/python2.7/site-packages/mako/runtime.py", line 824, > in _exec_template > callable_(context, *args, **kwargs) > File > "/tmp/piglit/html-summary/home/kwg/Projects/piglit/templates/index.mako.py", > line 115, in render_body > if line['class'] not in exclude and line['href'] is not None: > File "/home/kwg/Projects/piglit/framework/status.py", line 139, in __eq__ > return int(self) == int(other) > ValueError: invalid literal for int() with base 10: 'skip' @#$& -e option. I never should have written it, all I do is break it. sigh. :( signature.asc Description: This is a digitally signed message part. ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH v3 1/2] summary.py: Treat subtests as groups
On 11/14/2013 10:26 AM, Dylan Baker wrote: > This patch causes tests with subtests to be treated as a group, rather > than as a test. This means that the status the test itself stores will > be overwritten by those in the subtest. > > There is one oddity about this to be aware of; a test with subtests that > crashes or fails before any of the subtests run will report a fraction > of 0/1 with the appropriate color, even though all of the subtests will > report Not Run. > > v2: - Add subtests to the results file as full tests (the internal view > of the json), without this they will not appear in changes, fixes, > etc > - Render the background color of Not Run tests correctly in HTML > - Apply subtest fractions down the stack > v3: - Don't generate a link for Not Run tests in html page > > Tested-by: Tom Stellard > Signed-off-by: Dylan Baker This patch breaks summary generation for me - on the most basic of cases (piglit-run twice, summary), so I have serious doubts that you actually tested it. If you make last minute changes to your patch, you still need to retest it. Here is the traceback: >> rm -rf summary; ./piglit-summary-html.py -e pass -e skip summary results/batch-* Traceback (most recent call last): File "./piglit-summary-html.py", line 98, in main() File "./piglit-summary-html.py", line 94, in main output.generate_html(args.summaryDir, args.exclude_details) File "/home/kwg/Projects/piglit/framework/summary.py", line 477, in generate_html exclude=exclude)) File "/usr/lib64/python2.7/site-packages/mako/template.py", line 412, in render return runtime._render(self, self.callable_, args, data) File "/usr/lib64/python2.7/site-packages/mako/runtime.py", line 766, in _render **_kwargs_for_callable(callable_, data)) File "/usr/lib64/python2.7/site-packages/mako/runtime.py", line 798, in _render_context _exec_template(inherit, lclcontext, args=args, kwargs=kwargs) File "/usr/lib64/python2.7/site-packages/mako/runtime.py", line 824, in _exec_template callable_(context, *args, **kwargs) File "/tmp/piglit/html-summary/home/kwg/Projects/piglit/templates/index.mako.py", line 115, in render_body if line['class'] not in exclude and line['href'] is not None: File "/home/kwg/Projects/piglit/framework/status.py", line 139, in __eq__ return int(self) == int(other) ValueError: invalid literal for int() with base 10: 'skip' ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH 3/6] dmesg: setup dmesg to be able to mark a test warn or fail
Why not to have both? Marek On Fri, Nov 15, 2013 at 7:33 PM, Dylan Baker wrote: > On Friday, November 15, 2013 06:28:41 PM Marek Olšák wrote: >> I'll gladly type --dmesg=radeon. >> >> I have my own script for running piglit anyway, which calls piglit-run >> and piglit-summary-html, and the result and summary directories are >> named $(date)_$(time)_$(GLrenderer)_$(test_filters), and it can do a >> couple of other things. >> >> Marek >> >> On Fri, Nov 15, 2013 at 5:26 PM, Dylan Baker > wrote: >> > On Friday, November 15, 2013 10:42:11 AM Daniel Vetter wrote: >> >> On Thu, Nov 14, 2013 at 10:35:03AM -0800, Dylan Baker wrote: >> >> > On Thursday, November 14, 2013 05:34:38 PM Daniel Vetter wrote: >> >> > > On Thu, Nov 14, 2013 at 08:04:20AM -0800, Dylan Baker wrote: >> >> > > > On Thursday, November 14, 2013 02:52:41 PM Daniel Vetter wrote: >> >> > > > > On Tue, Nov 12, 2013 at 07:54:01AM -0800, Dylan Baker wrote: >> >> > > > > > This gives the dmesg class lists of statuses that will make a >> >> > > > > > test >> >> > > > > > a >> >> > > > > > warn or a fail, it includes a few basic checks, namely i915 >> >> > > > > > errors >> >> > > > > > and >> >> > > > > > that tests have not segfaulted. >> >> > > > > > >> >> > > > > > Signed-off-by: Dylan Baker >> >> > > > > > --- >> >> > > > > > >> >> > > > > > framework/dmesg.py| 36 >> >> > > > > > >> >> > > > > > framework/exectest.py | 22 +++--- >> >> > > > > > 2 files changed, 47 insertions(+), 11 deletions(-) >> >> > > > > > >> >> > > > > > diff --git a/framework/dmesg.py b/framework/dmesg.py >> >> > > > > > index 9a23c14..edbea88 100644 >> >> > > > > > --- a/framework/dmesg.py >> >> > > > > > +++ b/framework/dmesg.py >> >> > > > > > @@ -22,6 +22,7 @@ >> >> > > > > > >> >> > > > > > """ Module implementing classes for reading posix dmesg """ >> >> > > > > > >> >> > > > > > import os >> >> > > > > > >> >> > > > > > +import re >> >> > > > > > >> >> > > > > > import subprocess >> >> > > > > > from threads import synchronized_self >> >> > > > > > >> >> > > > > > @@ -29,8 +30,10 @@ __all__ = ['Dmesg'] >> >> > > > > > >> >> > > > > > # plain text list of statuses to be considered either a warn >> >> > > > > > or a >> >> > > > > > fail, >> >> > > > > > any >> >> > > > > > # statuses not on this list will simply be ignored. >> >> > > > > > >> >> > > > > > -WARN_STATUSES = [] >> >> > > > > > -FAIL_STATUSES = [] >> >> > > > > > +WARN_STATUSES = ['segfault'] >> >> > > > > > +FAIL_STATUSES = ['\[drm:.*\] \*ERROR\*', >> >> > > > > > + '\[drm\] stuck on [a-zA-Z]* ring', >> >> > > > > > + '\[drm\] GPU crash dump saved'] >> >> > > > > >> >> > > > > I think now that we filter out all the info/debug noise maybe we >> >> > > > > could >> >> > > > > go >> >> > > > > the other direction and blacklist a few of the remaining things >> >> > > > > from >> >> > > > > the >> >> > > > > core kernel we don't care about. E.g. >> >> > > > > >> >> > > > > [ 3867.022895] gem_evict_every (2671) used greatest stack depth: >> >> > > > > 2216 >> >> > > > > bytes >> >> > > > > left >> >> > > > > >> >> > > > > is a warn level message, but I don't care one bit about it (as >> >> > > > > long >> >> > > > > as >> >> > > > > it >> >> > > > > doesn't approach 0). But there's other warn level stuff which is >> >> > > > > fairly >> >> > > > > interesting. >> >> > > > > >> >> > > > > Just something to throw out there, I'm not sure what the best way >> >> > > > > would >> >> > > > > be >> >> > > > > to integrate dmesg reporting for piglit in general. >> >> > > > > -Daniel >> >> > > > >> >> > > > My personal problem with the dmesg code we have now (and with >> >> > > > *just* >> >> > > > blacklisting) is that I have an alps touchpad, it spams dmesg about >> >> > > > 10 >> >> > > > times a minute, so I can't use dmesg reporting because of the >> >> > > > massive >> >> > > > number of false positives; we could use some combination of >> >> > > > blacklisting >> >> > > > and whitelisting however. >> >> > > >> >> > > That sounds like we need a piglit cmdline option to supply a regex to >> >> > > filter out crap like that ... Or is the alps touchpad driver so bad >> >> > > there's not even a regex we could match it all against? >> >> > > -Daniel >> >> > >> >> > My concern is more that trying to filter out things we don't want seems >> >> > like an uphill battle that will become expensive quickly. First it's my >> >> > touchpad, then it's so and so's usb, and so on. I'm giong to ask some >> >> > of >> >> > the mesa guys here in the office to weigh in with their thoughts, since >> >> > they're all around today, snice I'm basing interest on one developer's >> >> > opinions. >> >> >> >> That's kinda what the cmdline would be for, to get rid of >> >> machine-specific >> >> stuff like your touchpad. I'm retesting igt on all the machines I have >> >> here right now, and thus far the stack usage warning is the only offe
Re: [Piglit] [PATCH 3/6] dmesg: setup dmesg to be able to mark a test warn or fail
On Friday, November 15, 2013 06:28:41 PM Marek Olšák wrote: > I'll gladly type --dmesg=radeon. > > I have my own script for running piglit anyway, which calls piglit-run > and piglit-summary-html, and the result and summary directories are > named $(date)_$(time)_$(GLrenderer)_$(test_filters), and it can do a > couple of other things. > > Marek > > On Fri, Nov 15, 2013 at 5:26 PM, Dylan Baker wrote: > > On Friday, November 15, 2013 10:42:11 AM Daniel Vetter wrote: > >> On Thu, Nov 14, 2013 at 10:35:03AM -0800, Dylan Baker wrote: > >> > On Thursday, November 14, 2013 05:34:38 PM Daniel Vetter wrote: > >> > > On Thu, Nov 14, 2013 at 08:04:20AM -0800, Dylan Baker wrote: > >> > > > On Thursday, November 14, 2013 02:52:41 PM Daniel Vetter wrote: > >> > > > > On Tue, Nov 12, 2013 at 07:54:01AM -0800, Dylan Baker wrote: > >> > > > > > This gives the dmesg class lists of statuses that will make a > >> > > > > > test > >> > > > > > a > >> > > > > > warn or a fail, it includes a few basic checks, namely i915 > >> > > > > > errors > >> > > > > > and > >> > > > > > that tests have not segfaulted. > >> > > > > > > >> > > > > > Signed-off-by: Dylan Baker > >> > > > > > --- > >> > > > > > > >> > > > > > framework/dmesg.py| 36 > >> > > > > > > >> > > > > > framework/exectest.py | 22 +++--- > >> > > > > > 2 files changed, 47 insertions(+), 11 deletions(-) > >> > > > > > > >> > > > > > diff --git a/framework/dmesg.py b/framework/dmesg.py > >> > > > > > index 9a23c14..edbea88 100644 > >> > > > > > --- a/framework/dmesg.py > >> > > > > > +++ b/framework/dmesg.py > >> > > > > > @@ -22,6 +22,7 @@ > >> > > > > > > >> > > > > > """ Module implementing classes for reading posix dmesg """ > >> > > > > > > >> > > > > > import os > >> > > > > > > >> > > > > > +import re > >> > > > > > > >> > > > > > import subprocess > >> > > > > > from threads import synchronized_self > >> > > > > > > >> > > > > > @@ -29,8 +30,10 @@ __all__ = ['Dmesg'] > >> > > > > > > >> > > > > > # plain text list of statuses to be considered either a warn > >> > > > > > or a > >> > > > > > fail, > >> > > > > > any > >> > > > > > # statuses not on this list will simply be ignored. > >> > > > > > > >> > > > > > -WARN_STATUSES = [] > >> > > > > > -FAIL_STATUSES = [] > >> > > > > > +WARN_STATUSES = ['segfault'] > >> > > > > > +FAIL_STATUSES = ['\[drm:.*\] \*ERROR\*', > >> > > > > > + '\[drm\] stuck on [a-zA-Z]* ring', > >> > > > > > + '\[drm\] GPU crash dump saved'] > >> > > > > > >> > > > > I think now that we filter out all the info/debug noise maybe we > >> > > > > could > >> > > > > go > >> > > > > the other direction and blacklist a few of the remaining things > >> > > > > from > >> > > > > the > >> > > > > core kernel we don't care about. E.g. > >> > > > > > >> > > > > [ 3867.022895] gem_evict_every (2671) used greatest stack depth: > >> > > > > 2216 > >> > > > > bytes > >> > > > > left > >> > > > > > >> > > > > is a warn level message, but I don't care one bit about it (as > >> > > > > long > >> > > > > as > >> > > > > it > >> > > > > doesn't approach 0). But there's other warn level stuff which is > >> > > > > fairly > >> > > > > interesting. > >> > > > > > >> > > > > Just something to throw out there, I'm not sure what the best way > >> > > > > would > >> > > > > be > >> > > > > to integrate dmesg reporting for piglit in general. > >> > > > > -Daniel > >> > > > > >> > > > My personal problem with the dmesg code we have now (and with > >> > > > *just* > >> > > > blacklisting) is that I have an alps touchpad, it spams dmesg about > >> > > > 10 > >> > > > times a minute, so I can't use dmesg reporting because of the > >> > > > massive > >> > > > number of false positives; we could use some combination of > >> > > > blacklisting > >> > > > and whitelisting however. > >> > > > >> > > That sounds like we need a piglit cmdline option to supply a regex to > >> > > filter out crap like that ... Or is the alps touchpad driver so bad > >> > > there's not even a regex we could match it all against? > >> > > -Daniel > >> > > >> > My concern is more that trying to filter out things we don't want seems > >> > like an uphill battle that will become expensive quickly. First it's my > >> > touchpad, then it's so and so's usb, and so on. I'm giong to ask some > >> > of > >> > the mesa guys here in the office to weigh in with their thoughts, since > >> > they're all around today, snice I'm basing interest on one developer's > >> > opinions. > >> > >> That's kinda what the cmdline would be for, to get rid of > >> machine-specific > >> stuff like your touchpad. I'm retesting igt on all the machines I have > >> here right now, and thus far the stack usage warning is the only offender > >> I've seend which wasn't a genuine issue. But yeah, more input should > >> definitely help. > >> -Daniel > > > > So if I'm understanding correctly, you're asking users to
Re: [Piglit] [PATCH v3 1/2] summary.py: Treat subtests as groups
On Friday, November 15, 2013 06:25:48 PM Damien Lespiau wrote: > On Thu, Nov 14, 2013 at 10:26:08AM -0800, Dylan Baker wrote: > > This patch causes tests with subtests to be treated as a group, rather > > than as a test. This means that the status the test itself stores will > > be overwritten by those in the subtest. > > > > There is one oddity about this to be aware of; a test with subtests that > > crashes or fails before any of the subtests run will report a fraction > > of 0/1 with the appropriate color, even though all of the subtests will > > report Not Run. > > > > v2: - Add subtests to the results file as full tests (the internal view > > > > of the json), without this they will not appear in changes, fixes, > > etc > > > > - Render the background color of Not Run tests correctly in HTML > > - Apply subtest fractions down the stack > > > > v3: - Don't generate a link for Not Run tests in html page > > > > Tested-by: Tom Stellard > > Signed-off-by: Dylan Baker > > This patch regresses the HTML output here. For tests that do run-time > checks and return 77 (skip), they are now marked as "Not Run" instead of > "skip". This also matters because skip had a link to the details and the > output of skipped tests is usally of interest (it has the reason of the > skip) > > Mind fixing this? I'll have a look signature.asc Description: This is a digitally signed message part. ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH v3 1/2] summary.py: Treat subtests as groups
On Thu, Nov 14, 2013 at 10:26:08AM -0800, Dylan Baker wrote: > This patch causes tests with subtests to be treated as a group, rather > than as a test. This means that the status the test itself stores will > be overwritten by those in the subtest. > > There is one oddity about this to be aware of; a test with subtests that > crashes or fails before any of the subtests run will report a fraction > of 0/1 with the appropriate color, even though all of the subtests will > report Not Run. > > v2: - Add subtests to the results file as full tests (the internal view > of the json), without this they will not appear in changes, fixes, > etc > - Render the background color of Not Run tests correctly in HTML > - Apply subtest fractions down the stack > v3: - Don't generate a link for Not Run tests in html page > > Tested-by: Tom Stellard > Signed-off-by: Dylan Baker This patch regresses the HTML output here. For tests that do run-time checks and return 77 (skip), they are now marked as "Not Run" instead of "skip". This also matters because skip had a link to the details and the output of skipped tests is usally of interest (it has the reason of the skip) Mind fixing this? -- Damien ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
[Piglit] [PATCH 3/3] Split resume functionality out of piglit-run.py
The resume functionality actually shares only a little boilerplate with
the run functionality, and there is a lot of extra boilerplate that
exists (or should exist) to make resumes work correctly with all of the
command line options allowed by piglit-run. Therefore, it makes more
sense to split it out into it's own file.
Signed-off-by: Dylan Baker
---
CMakeLists.txt | 1 +
piglit-resume.py | 84
piglit-run.py| 40 +++
3 files changed, 89 insertions(+), 36 deletions(-)
create mode 100755 piglit-resume.py
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 9bbffe9..e952e24 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -366,6 +366,7 @@ install (
piglit-merge-results.py
piglit-print-commands.py
piglit-run.py
+ piglit-resume.py
piglit-summary.py
piglit-summary-html.py
piglit-summary-junit.py
diff --git a/piglit-resume.py b/piglit-resume.py
new file mode 100755
index 000..ae5de9b
--- /dev/null
+++ b/piglit-resume.py
@@ -0,0 +1,84 @@
+#!/usr/bin/env python
+#
+# Permission is hereby granted, free of charge, to any person
+# obtaining a copy of this software and associated documentation
+# files (the "Software"), to deal in the Software without
+# restriction, including without limitation the rights to use,
+# copy, modify, merge, publish, distribute, sublicense, and/or
+# sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following
+# conditions:
+#
+# This permission notice shall be included in all copies or
+# substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
+# KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
+# WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
+# PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHOR(S) BE
+# LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
+# OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+import sys
+import os
+import os.path as path
+import argparse
+
+import framework.core as core
+
+
+def main():
+parser = argparse.ArgumentParser()
+parser.add_argument("results_path",
+type=path.realpath,
+metavar="",
+help="Path to results folder")
+args = parser.parse_args()
+
+results = core.load_results(args.results_path)
+env = core.Environment(concurrent=results.options['concurrent'],
+ exclude_filter=results.options['exclude_filter'],
+ include_filter=results.options['filter'],
+ execute=results.options['execute'],
+ valgrind=results.options['valgrind'],
+ dmesg=results.options['dmesg'])
+
+# Change working directory to the piglit directory
+os.chdir(path.dirname(path.realpath(sys.argv[0])))
+
+results_path = path.join(args.results_path, "main")
+json_writer = core.JSONWriter(open(results_path, 'w+'))
+json_writer.open_dict()
+json_writer.write_dict_key("options")
+json_writer.open_dict()
+for key, value in results.options.iteritems():
+json_writer.write_dict_item(key, value)
+json_writer.close_dict()
+
+json_writer.write_dict_item('name', results.name)
+for (key, value) in env.collectData().items():
+json_writer.write_dict_item(key, value)
+
+json_writer.write_dict_key('tests')
+json_writer.open_dict()
+for key, value in results.tests.iteritems():
+json_writer.write_dict_item(key, value)
+env.exclude_tests.add(key)
+json_writer.close_dict()
+
+profile = core.loadTestProfile(results.options['profile'])
+# This is resumed, don't bother with time since it wont be accurate anyway
+profile.run(env, json_writer)
+
+json_writer.close_dict()
+json_writer.close_dict()
+json_writer.file.close()
+
+print("\n"
+ "Thank you for running Piglit!\n"
+ "Results have ben wrriten to {0}".format(results_path))
+
+if __name__ == "__main__":
+main()
\ No newline at end of file
diff --git a/piglit-run.py b/piglit-run.py
index 41ee5ca..0d3d1be 100755
--- a/piglit-run.py
+++ b/piglit-run.py
@@ -36,17 +36,10 @@ from framework.threads import synchronized_self
def main():
parser = argparse.ArgumentParser(sys.argv)
-# Either require that a name for the test is passed or that
-# resume is requested
-excGroup1 = parser.add_mutually_exclusive_group()
-excGroup1.add_argument("-n", "--name",
- metavar="",
- default=None,
- help="Name of this test run")
-excGroup1
[Piglit] [PATCH 2/3] piglit-run.py: Record all attributes of Environment and restore them
This causes all attributes in the Environment instance env to be dumped
into the json and reloaded on a resume. It adds an __iter__ magic method
to core.Environment to allow this.
Signed-off-by: Dylan Baker
---
framework/core.py | 5 +
piglit-run.py | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/framework/core.py b/framework/core.py
index 55ce06b..51c0380 100644
--- a/framework/core.py
+++ b/framework/core.py
@@ -62,6 +62,8 @@ class PiglitJSONEncoder(json.JSONEncoder):
def default(self, o):
if isinstance(o, status.Status):
return str(o)
+elif isinstance(o, set):
+return list(o)
return json.JSONEncoder.default(self, o)
class JSONWriter:
@@ -414,6 +416,9 @@ class Environment:
for each in exclude_filter:
self.exclude_filter.append(re.compile(each))
+def __iter__(self):
+return self.__dict__.iteritems()
+
def run(self, command):
try:
p = subprocess.Popen(command,
diff --git a/piglit-run.py b/piglit-run.py
index 86448ae..41ee5ca 100755
--- a/piglit-run.py
+++ b/piglit-run.py
@@ -136,8 +136,8 @@ def main():
json_writer.write_dict_key('options')
json_writer.open_dict()
json_writer.write_dict_item('profile', args.test_profile)
-json_writer.write_dict_item('filter', args.include_tests)
-json_writer.write_dict_item('exclude_filter', args.exclude_tests)
+for key, value in env:
+json_writer.write_dict_item(key, value)
json_writer.close_dict()
json_writer.write_dict_item('name', results.name)
--
1.8.3.2
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
[Piglit] [PATCH 1/3] piglit-run.py: Cleanups
This patch tidies up a few things, and lays groundwork for later patches
in this series.
Signed-off-by: Dylan Baker
---
piglit-run.py | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/piglit-run.py b/piglit-run.py
index 1d63cd4..86448ae 100755
--- a/piglit-run.py
+++ b/piglit-run.py
@@ -77,27 +77,25 @@ def main():
action="store_true",
help="Capture a difference in dmesg before and "
"after each test")
-parser.add_argument("testProfile",
+parser.add_argument("test_profile",
metavar="",
help="Path to testfile to run")
-parser.add_argument("resultsPath",
+parser.add_argument("results_path",
+type=path.realpath,
metavar="",
help="Path to results folder")
args = parser.parse_args()
# Set the platform to pass to waffle
-if args.platform is not None:
+if args.platform:
os.environ['PIGLIT_PLATFORM'] = args.platform
-# Always Convert Results Path from Relative path to Actual Path.
-resultsDir = path.realpath(args.resultsPath)
-
# If resume is requested attempt to load the results file
# in the specified path
if args.resume is True:
# Load settings from the old results JSON
-old_results = core.load_results(resultsDir)
-profileFilename = old_results.options['profile']
+old_results = core.load_results(args.results_path)
+args.test_profile = old_results.options['profile']
# Changing the args to the old args allows us to set them
# all in one places down the way
@@ -105,8 +103,6 @@ def main():
args.include_tests = old_results.options['filter']
# Otherwise parse additional settings from the command line
-else:
-profileFilename = args.testProfile
# Pass arguments into Environment
env = core.Environment(concurrent=args.concurrency,
@@ -120,7 +116,7 @@ def main():
piglit_dir = path.dirname(path.realpath(sys.argv[0]))
os.chdir(piglit_dir)
-core.checkDir(resultsDir, False)
+core.checkDir(args.results_path, False)
results = core.TestrunResult()
@@ -128,10 +124,10 @@ def main():
if args.name is not None:
results.name = args.name
else:
-results.name = path.basename(resultsDir)
+results.name = path.basename(args.results_path)
# Begin json.
-result_filepath = os.path.join(resultsDir, 'main')
+result_filepath = path.join(args.results_path, 'main')
result_file = open(result_filepath, 'w')
json_writer = core.JSONWriter(result_file)
json_writer.open_dict()
@@ -139,7 +135,7 @@ def main():
# Write out command line options for use in resuming.
json_writer.write_dict_key('options')
json_writer.open_dict()
-json_writer.write_dict_item('profile', profileFilename)
+json_writer.write_dict_item('profile', args.test_profile)
json_writer.write_dict_item('filter', args.include_tests)
json_writer.write_dict_item('exclude_filter', args.exclude_tests)
json_writer.close_dict()
@@ -148,7 +144,7 @@ def main():
for (key, value) in env.collectData().items():
json_writer.write_dict_item(key, value)
-profile = core.loadTestProfile(profileFilename)
+profile = core.loadTestProfile(args.test_profile)
json_writer.write_dict_key('tests')
json_writer.open_dict()
--
1.8.3.2
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH 3/6] dmesg: setup dmesg to be able to mark a test warn or fail
I'll gladly type --dmesg=radeon. I have my own script for running piglit anyway, which calls piglit-run and piglit-summary-html, and the result and summary directories are named $(date)_$(time)_$(GLrenderer)_$(test_filters), and it can do a couple of other things. Marek On Fri, Nov 15, 2013 at 5:26 PM, Dylan Baker wrote: > On Friday, November 15, 2013 10:42:11 AM Daniel Vetter wrote: >> On Thu, Nov 14, 2013 at 10:35:03AM -0800, Dylan Baker wrote: >> > On Thursday, November 14, 2013 05:34:38 PM Daniel Vetter wrote: >> > > On Thu, Nov 14, 2013 at 08:04:20AM -0800, Dylan Baker wrote: >> > > > On Thursday, November 14, 2013 02:52:41 PM Daniel Vetter wrote: >> > > > > On Tue, Nov 12, 2013 at 07:54:01AM -0800, Dylan Baker wrote: >> > > > > > This gives the dmesg class lists of statuses that will make a test >> > > > > > a >> > > > > > warn or a fail, it includes a few basic checks, namely i915 errors >> > > > > > and >> > > > > > that tests have not segfaulted. >> > > > > > >> > > > > > Signed-off-by: Dylan Baker >> > > > > > --- >> > > > > > >> > > > > > framework/dmesg.py| 36 >> > > > > > framework/exectest.py | 22 +++--- >> > > > > > 2 files changed, 47 insertions(+), 11 deletions(-) >> > > > > > >> > > > > > diff --git a/framework/dmesg.py b/framework/dmesg.py >> > > > > > index 9a23c14..edbea88 100644 >> > > > > > --- a/framework/dmesg.py >> > > > > > +++ b/framework/dmesg.py >> > > > > > @@ -22,6 +22,7 @@ >> > > > > > >> > > > > > """ Module implementing classes for reading posix dmesg """ >> > > > > > >> > > > > > import os >> > > > > > >> > > > > > +import re >> > > > > > >> > > > > > import subprocess >> > > > > > from threads import synchronized_self >> > > > > > >> > > > > > @@ -29,8 +30,10 @@ __all__ = ['Dmesg'] >> > > > > > >> > > > > > # plain text list of statuses to be considered either a warn or a >> > > > > > fail, >> > > > > > any >> > > > > > # statuses not on this list will simply be ignored. >> > > > > > >> > > > > > -WARN_STATUSES = [] >> > > > > > -FAIL_STATUSES = [] >> > > > > > +WARN_STATUSES = ['segfault'] >> > > > > > +FAIL_STATUSES = ['\[drm:.*\] \*ERROR\*', >> > > > > > + '\[drm\] stuck on [a-zA-Z]* ring', >> > > > > > + '\[drm\] GPU crash dump saved'] >> > > > > >> > > > > I think now that we filter out all the info/debug noise maybe we >> > > > > could >> > > > > go >> > > > > the other direction and blacklist a few of the remaining things from >> > > > > the >> > > > > core kernel we don't care about. E.g. >> > > > > >> > > > > [ 3867.022895] gem_evict_every (2671) used greatest stack depth: >> > > > > 2216 >> > > > > bytes >> > > > > left >> > > > > >> > > > > is a warn level message, but I don't care one bit about it (as long >> > > > > as >> > > > > it >> > > > > doesn't approach 0). But there's other warn level stuff which is >> > > > > fairly >> > > > > interesting. >> > > > > >> > > > > Just something to throw out there, I'm not sure what the best way >> > > > > would >> > > > > be >> > > > > to integrate dmesg reporting for piglit in general. >> > > > > -Daniel >> > > > >> > > > My personal problem with the dmesg code we have now (and with *just* >> > > > blacklisting) is that I have an alps touchpad, it spams dmesg about 10 >> > > > times a minute, so I can't use dmesg reporting because of the massive >> > > > number of false positives; we could use some combination of >> > > > blacklisting >> > > > and whitelisting however. >> > > >> > > That sounds like we need a piglit cmdline option to supply a regex to >> > > filter out crap like that ... Or is the alps touchpad driver so bad >> > > there's not even a regex we could match it all against? >> > > -Daniel >> > >> > My concern is more that trying to filter out things we don't want seems >> > like an uphill battle that will become expensive quickly. First it's my >> > touchpad, then it's so and so's usb, and so on. I'm giong to ask some of >> > the mesa guys here in the office to weigh in with their thoughts, since >> > they're all around today, snice I'm basing interest on one developer's >> > opinions. >> >> That's kinda what the cmdline would be for, to get rid of machine-specific >> stuff like your touchpad. I'm retesting igt on all the machines I have >> here right now, and thus far the stack usage warning is the only offender >> I've seend which wasn't a genuine issue. But yeah, more input should >> definitely help. >> -Daniel > > So if I'm understanding correctly, you're asking users to craft regex on the > commandline every time they run piglit? that sounds like a nightmare. ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] framework: Fix resuming of previous runs
On Fri, Nov 15, 2013 at 08:51:42AM -0800, Dylan Baker wrote: > > This looks fine. I had implemented this when I did the status work, but then > > didn't think I needed it. Resume is not a commonly used feature obviously. FWIW, it's something we really need working with the i915 test-suite in intel-gpu-tools. Some tests there are not very gentle and are likely to cause hard hangs. Thanks for the review. -- Damien ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH v2 1/2] piglit-run.py: record whether the test run was concurrent
On Fri, Nov 15, 2013 at 08:55:23AM -0800, Dylan Baker wrote: > cc: b...@bwidawsk.net > Signed-off-by: Dylan Baker For the 2 patches: Reviewed-by: Damien Lespiau ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
[Piglit] [PATCH v2 2/2] piglit-run.py: resume honors saved concurrency flag
This breaks incomplete runs started before applying the previous patch in this series, since there will be no key for concurrency v2: - Add this patch (Damien Lespiau) Signed-off-by: Dylan Baker --- piglit-run.py | 1 + 1 file changed, 1 insertion(+) diff --git a/piglit-run.py b/piglit-run.py index 4aa5929..4f51767 100755 --- a/piglit-run.py +++ b/piglit-run.py @@ -103,6 +103,7 @@ def main(): # all in one places down the way args.exclude_tests = old_results.options['exclude_filter'] args.include_tests = old_results.options['filter'] +args.concurrency = old_results.options['concurrency'] # Otherwise parse additional settings from the command line else: -- 1.8.3.2 ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
[Piglit] [PATCH v2 1/2] piglit-run.py: record whether the test run was concurrent
cc: b...@bwidawsk.net
Signed-off-by: Dylan Baker
---
piglit-run.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/piglit-run.py b/piglit-run.py
index 1d63cd4..4aa5929 100755
--- a/piglit-run.py
+++ b/piglit-run.py
@@ -142,6 +142,7 @@ def main():
json_writer.write_dict_item('profile', profileFilename)
json_writer.write_dict_item('filter', args.include_tests)
json_writer.write_dict_item('exclude_filter', args.exclude_tests)
+json_writer.write_dict_item('concurrency', args.concurrency)
json_writer.close_dict()
json_writer.write_dict_item('name', results.name)
--
1.8.3.2
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] framework: Fix resuming of previous runs
On Friday, November 15, 2013 08:37:27 AM Dylan Baker wrote: > On Thursday, November 14, 2013 06:03:54 PM Damien Lespiau wrote: > > When resuming and loading the partial JSON file from disk, the 'status' > > property is replaced by status.Status objects. When serializing back > > those objects, JSONEncoder is unhappy because it doesn't know how to > > > > serialize status.Status objects and gives up with exceptions like: > > TypeError: skip is not JSON serializable > > > > We can write a small subclass of JSONEncoder that knows about Status > > objects and use it to do the initial write back of the partial JSON > > file. > > > > Signed-off-by: Damien Lespiau > > --- > > > > framework/core.py | 7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/framework/core.py b/framework/core.py > > index 2d5d0dc..9f153a3 100644 > > --- a/framework/core.py > > +++ b/framework/core.py > > @@ -58,6 +58,11 @@ __all__ = ['Environment', > > > > 'Test', > > 'testBinDir'] > > > > +class PiglitJSONEncoder(json.JSONEncoder): > > +def default(self, o): > > +if isinstance(o, status.Status): > > +return str(o) > > +return json.JSONEncoder.default(self, o) > > > > class JSONWriter: > > ''' > > > > @@ -108,7 +113,7 @@ class JSONWriter: > > self.file = file > > self.__indent_level = 0 > > self.__inhibit_next_indent = False > > > > -self.__encoder = json.JSONEncoder(indent=self.INDENT) > > +self.__encoder = PiglitJSONEncoder(indent=self.INDENT) > > > > # self.__is_collection_empty > > # > > This looks fine. I had implemented this when I did the status work, but then > didn't think I needed it. Resume is not a commonly used feature obviously. > > Reviewed-by: Dylan Baker I went ahead and pushed this signature.asc Description: This is a digitally signed message part. ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] framework: Fix resuming of previous runs
On Thursday, November 14, 2013 06:03:54 PM Damien Lespiau wrote: > When resuming and loading the partial JSON file from disk, the 'status' > property is replaced by status.Status objects. When serializing back > those objects, JSONEncoder is unhappy because it doesn't know how to > serialize status.Status objects and gives up with exceptions like: > > TypeError: skip is not JSON serializable > > We can write a small subclass of JSONEncoder that knows about Status > objects and use it to do the initial write back of the partial JSON > file. > > Signed-off-by: Damien Lespiau > --- > framework/core.py | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/framework/core.py b/framework/core.py > index 2d5d0dc..9f153a3 100644 > --- a/framework/core.py > +++ b/framework/core.py > @@ -58,6 +58,11 @@ __all__ = ['Environment', > 'Test', > 'testBinDir'] > > +class PiglitJSONEncoder(json.JSONEncoder): > +def default(self, o): > +if isinstance(o, status.Status): > +return str(o) > +return json.JSONEncoder.default(self, o) > > class JSONWriter: > ''' > @@ -108,7 +113,7 @@ class JSONWriter: > self.file = file > self.__indent_level = 0 > self.__inhibit_next_indent = False > -self.__encoder = json.JSONEncoder(indent=self.INDENT) > +self.__encoder = PiglitJSONEncoder(indent=self.INDENT) > > # self.__is_collection_empty > # This looks fine. I had implemented this when I did the status work, but then didn't think I needed it. Resume is not a commonly used feature obviously. Reviewed-by: Dylan Baker signature.asc Description: This is a digitally signed message part. ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] framework: Humanize time values in the HTML report
On Friday, November 15, 2013 04:26:07 PM Damien Lespiau wrote: > On Fri, Nov 15, 2013 at 08:11:07AM -0800, Dylan Baker wrote: > > > +if amount == 'None': > > > +return 'None' > > > > the python idiom is 'if not amount: return None' > > These are strings, not the built-in. Doh, that's what I get for reviewing patches first thing in the morning :) > > > on a more practicle note, why roll all of this instead of just using > > datetime.timedelta? > > Because it was giving me much more control on how I wanted to display > the time, as you can see. Yes, I guess what I'm really asking is since you've now dropped all times greater than hours is that format worth the extra code? IMHO HH:MM:SS:MS* is just as good as xMin, ySec, zMS, etc; when you consider that datetime.timedelta is provided by python, thus zero maintanence burden. signature.asc Description: This is a digitally signed message part. ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] framework: Dump the result of 'uname -a' in the report
On Friday, November 15, 2013 03:18:42 PM Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
> ---
> framework/core.py | 3 +++
> framework/summary.py| 1 +
> templates/testrun_info.mako | 6 ++
> 3 files changed, 10 insertions(+)
>
> diff --git a/framework/core.py b/framework/core.py
> index e0fe46c..e0b49f8 100644
> --- a/framework/core.py
> +++ b/framework/core.py
> @@ -293,11 +293,13 @@ class TestrunResult:
> self.serialized_keys = ['options',
> 'name',
> 'tests',
> +'uname',
> 'wglinfo',
> 'glxinfo',
> 'lspci',
> 'time_elapsed']
> self.name = None
> +self.uname = None
> self.glxinfo = None
> self.lspci = None
> self.time_elapsed = None
> @@ -432,6 +434,7 @@ class Environment:
> else:
> result['glxinfo'] = self.run('glxinfo')
> if system == 'Linux':
> +result['uname'] = self.run(['uname', '-a'])
> result['lspci'] = self.run('lspci')
> return result
>
> diff --git a/framework/summary.py b/framework/summary.py
> index a85353a..13596ea 100644
> --- a/framework/summary.py
> +++ b/framework/summary.py
> @@ -458,6 +458,7 @@ class Summary:
> out.write(testindex.render(name=each.name,
>
> time=humanize_time(each.time_elapsed), options=each.options,
> + uname=each.uname,
> glxinfo=each.glxinfo,
> lspci=each.lspci))
>
> diff --git a/templates/testrun_info.mako b/templates/testrun_info.mako
> index e6e00b3..6ff1f44 100644
> --- a/templates/testrun_info.mako
> +++ b/templates/testrun_info.mako
> @@ -30,6 +30,12 @@
> ${options}
>
>
> +uname -a
> +
> + ${uname}
> +
> +
> +
> lspci
>
>${lspci}
This looks fine.
Reviewed-by: Dylan Baker
signature.asc
Description: This is a digitally signed message part.
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH 3/6] dmesg: setup dmesg to be able to mark a test warn or fail
On Friday, November 15, 2013 10:42:11 AM Daniel Vetter wrote: > On Thu, Nov 14, 2013 at 10:35:03AM -0800, Dylan Baker wrote: > > On Thursday, November 14, 2013 05:34:38 PM Daniel Vetter wrote: > > > On Thu, Nov 14, 2013 at 08:04:20AM -0800, Dylan Baker wrote: > > > > On Thursday, November 14, 2013 02:52:41 PM Daniel Vetter wrote: > > > > > On Tue, Nov 12, 2013 at 07:54:01AM -0800, Dylan Baker wrote: > > > > > > This gives the dmesg class lists of statuses that will make a test > > > > > > a > > > > > > warn or a fail, it includes a few basic checks, namely i915 errors > > > > > > and > > > > > > that tests have not segfaulted. > > > > > > > > > > > > Signed-off-by: Dylan Baker > > > > > > --- > > > > > > > > > > > > framework/dmesg.py| 36 > > > > > > framework/exectest.py | 22 +++--- > > > > > > 2 files changed, 47 insertions(+), 11 deletions(-) > > > > > > > > > > > > diff --git a/framework/dmesg.py b/framework/dmesg.py > > > > > > index 9a23c14..edbea88 100644 > > > > > > --- a/framework/dmesg.py > > > > > > +++ b/framework/dmesg.py > > > > > > @@ -22,6 +22,7 @@ > > > > > > > > > > > > """ Module implementing classes for reading posix dmesg """ > > > > > > > > > > > > import os > > > > > > > > > > > > +import re > > > > > > > > > > > > import subprocess > > > > > > from threads import synchronized_self > > > > > > > > > > > > @@ -29,8 +30,10 @@ __all__ = ['Dmesg'] > > > > > > > > > > > > # plain text list of statuses to be considered either a warn or a > > > > > > fail, > > > > > > any > > > > > > # statuses not on this list will simply be ignored. > > > > > > > > > > > > -WARN_STATUSES = [] > > > > > > -FAIL_STATUSES = [] > > > > > > +WARN_STATUSES = ['segfault'] > > > > > > +FAIL_STATUSES = ['\[drm:.*\] \*ERROR\*', > > > > > > + '\[drm\] stuck on [a-zA-Z]* ring', > > > > > > + '\[drm\] GPU crash dump saved'] > > > > > > > > > > I think now that we filter out all the info/debug noise maybe we > > > > > could > > > > > go > > > > > the other direction and blacklist a few of the remaining things from > > > > > the > > > > > core kernel we don't care about. E.g. > > > > > > > > > > [ 3867.022895] gem_evict_every (2671) used greatest stack depth: > > > > > 2216 > > > > > bytes > > > > > left > > > > > > > > > > is a warn level message, but I don't care one bit about it (as long > > > > > as > > > > > it > > > > > doesn't approach 0). But there's other warn level stuff which is > > > > > fairly > > > > > interesting. > > > > > > > > > > Just something to throw out there, I'm not sure what the best way > > > > > would > > > > > be > > > > > to integrate dmesg reporting for piglit in general. > > > > > -Daniel > > > > > > > > My personal problem with the dmesg code we have now (and with *just* > > > > blacklisting) is that I have an alps touchpad, it spams dmesg about 10 > > > > times a minute, so I can't use dmesg reporting because of the massive > > > > number of false positives; we could use some combination of > > > > blacklisting > > > > and whitelisting however. > > > > > > That sounds like we need a piglit cmdline option to supply a regex to > > > filter out crap like that ... Or is the alps touchpad driver so bad > > > there's not even a regex we could match it all against? > > > -Daniel > > > > My concern is more that trying to filter out things we don't want seems > > like an uphill battle that will become expensive quickly. First it's my > > touchpad, then it's so and so's usb, and so on. I'm giong to ask some of > > the mesa guys here in the office to weigh in with their thoughts, since > > they're all around today, snice I'm basing interest on one developer's > > opinions. > > That's kinda what the cmdline would be for, to get rid of machine-specific > stuff like your touchpad. I'm retesting igt on all the machines I have > here right now, and thus far the stack usage warning is the only offender > I've seend which wasn't a genuine issue. But yeah, more input should > definitely help. > -Daniel So if I'm understanding correctly, you're asking users to craft regex on the commandline every time they run piglit? that sounds like a nightmare. signature.asc Description: This is a digitally signed message part. ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] framework: Humanize time values in the HTML report
On Fri, Nov 15, 2013 at 08:11:07AM -0800, Dylan Baker wrote: > > +if amount == 'None': > > +return 'None' > > the python idiom is 'if not amount: return None' These are strings, not the built-in. > on a more practicle note, why roll all of this instead of just using > datetime.timedelta? Because it was giving me much more control on how I wanted to display the time, as you can see. -- Damien ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] fbo-drawbuffers-maxtargets: use different colors for different buffers
- Original Message -
> Before, the test always drew green rects for all the target buffers.
> Now we draw a different color into each buffer to be more thorough.
>
> Plus, replace 16 with MAX_TARGETS, add some comments, etc.
>
> Note: the test now fails with Mesa's swrast because swrast errantly
> writes the same color to all render targets.
> ---
> tests/fbo/fbo-drawbuffers-maxtargets.c | 63
> ++--
> 1 file changed, 51 insertions(+), 12 deletions(-)
>
> diff --git a/tests/fbo/fbo-drawbuffers-maxtargets.c
> b/tests/fbo/fbo-drawbuffers-maxtargets.c
> index c7a8f7d..1efe819 100644
> --- a/tests/fbo/fbo-drawbuffers-maxtargets.c
> +++ b/tests/fbo/fbo-drawbuffers-maxtargets.c
> @@ -44,6 +44,8 @@ PIGLIT_GL_TEST_CONFIG_BEGIN
>
> PIGLIT_GL_TEST_CONFIG_END
>
> +#define MAX_TARGETS 16
> +
> static GLint max_targets;
>
> static char *vs_source =
> @@ -53,13 +55,37 @@ static char *vs_source =
> "}\n";
>
> static char *fs_source =
> + "uniform vec4 colors[16]; \n"
> "void main()\n"
> "{\n"
> " for (int i = 0; i < %d; i++) {\n"
> - " gl_FragData[i] = vec4(0.0, 1.0, 0.0, 0.0);\n"
> + " gl_FragData[i] = colors[i];\n"
> " }\n"
> "}\n";
>
> +static const float colors[][4] = {
> + { 1.0, 0.0, 0.0, 0.0 }, /* red */
> + { 0.0, 1.0, 0.0, 0.0 }, /* green */
> + { 0.0, 0.0, 1.0, 0.0 }, /* blue */
> + { 0.0, 1.0, 1.0, 0.0 }, /* cyan */
> +
> + { 1.0, 0.0, 1.0, 0.0 }, /* purple */
> + { 1.0, 1.0, 0.0, 0.0 }, /* green */
> + { 0.5, 0.0, 0.0, 0.0 }, /* half red */
> + { 0.0, 0.5, 0.0, 0.0 }, /* half green */
> +
> + { 0.0, 0.0, 0.5, 0.0 }, /* half blue */
> + { 0.0, 0.5, 0.5, 0.0 }, /* half cyan */
> + { 0.5, 0.0, 0.5, 0.0 }, /* half purple */
> + { 0.5, 0.5, 0.0, 0.0 }, /* half green */
> +
> + { 1.0, 1.0, 1.0, 0.0 },/* white */
> + { 0.75, 0.75, 0.75, 0.0 }, /* 75% gray */
> + { 0.5, 0.5, 0.5, 0.0 },/* 50% gray */
> + { 0.25, 0.25, 0.25, 0.0 } /* 25% gray */
> +};
> +
> +
> static GLuint
> attach_texture(int i)
> {
> @@ -87,10 +113,11 @@ attach_texture(int i)
> static void
> generate_and_display_drawbuffers(int count)
> {
> - GLuint tex[16], fb, fs, vs, prog;
> - GLenum attachments[16], status;
> + GLuint tex[MAX_TARGETS], fb, fs, vs, prog;
> + GLenum attachments[MAX_TARGETS], status;
> char *fs_count_source;
> int i;
> + int colors_uniform;
>
> glGenFramebuffersEXT(1, &fb);
> glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fb);
> @@ -112,7 +139,7 @@ generate_and_display_drawbuffers(int count)
> glClearColor(1.0, 0.0, 0.0, 0.0);
> glClear(GL_COLOR_BUFFER_BIT);
>
> - /* Build the shader that spams green to all outputs. */
> + /* Build the shader that writes different color to each buffer. */
> vs = piglit_compile_shader_text(GL_VERTEX_SHADER, vs_source);
>
> fs_count_source = malloc(strlen(fs_source) + 5);
> @@ -126,6 +153,9 @@ generate_and_display_drawbuffers(int count)
> if (!piglit_check_gl_error(GL_NO_ERROR))
> piglit_report_result(PIGLIT_FAIL);
>
> + colors_uniform = glGetUniformLocation(prog, "colors");
> + glUniform4fv(colors_uniform, MAX_TARGETS, (GLfloat *) colors);
> +
> /* Now render to all the color buffers. */
> piglit_draw_rect(-1, -1, 2, 2);
>
> @@ -135,6 +165,7 @@ generate_and_display_drawbuffers(int count)
> piglit_ortho_projection(piglit_width, piglit_height, GL_FALSE);
> glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
> glEnable(GL_TEXTURE_2D);
> + /* draw row of boxes, each with the color from texture/target[i] */
> for (i = 0; i < count; i++) {
> glBindTexture(GL_TEXTURE_2D, tex[i]);
> piglit_draw_rect_tex(16 * i, 16 * (count - 1),
> @@ -154,22 +185,24 @@ enum piglit_result
> piglit_display(void)
> {
> GLboolean pass = GL_TRUE;
> - float green[] = {0, 1, 0, 0};
> int count, i;
>
> glClearColor(0.5, 0.5, 0.5, 0.5);
> glClear(GL_COLOR_BUFFER_BIT);
>
> +
> for (count = 1; count <= max_targets; count++) {
> generate_and_display_drawbuffers(count);
> }
>
> + /* walk over rows */
> for (count = 1; count <= max_targets; count++) {
> + /* walk over columns */
> for (i = 0; i < count; i++) {
> pass = pass &&
> piglit_probe_pixel_rgb(16 * i + 8,
> 16 * (count - 1) + 8,
> -green);
> +colors[i]);
> }
> }
>
> @@ -183,9 +216,10 @@ piglit_init(int argc, char **argv)
> {
> GLint max_attachments;
>
> - printf("The result should be increasing lengths of rows of green\n"
> -
Re: [Piglit] [PATCH] glsl-1.10: test that redeclaring a variable with a different type is illegal
- Original Message -
> This passes w/ Mesa but crashes NVIDIA's driver.
> ---
> .../declarations/bad-variable-redeclaration.frag | 29
>
> 1 file changed, 29 insertions(+)
> create mode 100644
> tests/spec/glsl-1.10/compiler/declarations/bad-variable-redeclaration.frag
>
> diff --git
> a/tests/spec/glsl-1.10/compiler/declarations/bad-variable-redeclaration.frag
> b/tests/spec/glsl-1.10/compiler/declarations/bad-variable-redeclaration.frag
> new file mode 100644
> index 000..1354f14
> --- /dev/null
> +++
> b/tests/spec/glsl-1.10/compiler/declarations/bad-variable-redeclaration.frag
> @@ -0,0 +1,29 @@
> +/* [config]
> + * expect_result: fail
> + * glsl_version: 1.10
> + * [end config]
> + */
> +
> +
> +// This test checks that the compiler generates an error if we try
> +// declare two variables and a function with the same name.
> +// NVIDIA's 325.15 driver crashes on this.
> +
> +varying float color;
> +
> +float foo;
> +
> +// Redeclaring foo here should generate an error
> +int foo;
> +
> +// This causes NVIDIA's driver to crash:
> +vec4 foo(float v)
> +{
> + return vec4(v);
> +}
> +
> +void main()
> +{
> + gl_FragColor = color;
> +}
> +
> --
> 1.7.10.4
>
> ___
> Piglit mailing list
> Piglit@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/piglit
>
Reviewed-by: Jose Fonseca
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] framework: Humanize time values in the HTML report
On Friday, November 15, 2013 09:06:51 AM Damien Lespiau wrote:
> It's a bit hard to parse raw seconds, so make those time values easier
> to read while trying to preserve roughly enough relevant precision to be
> useful.
>
> It gives strings like:
>
> 22.4ms
> 7.798s
> 42s
> 7min 25s
> ...
>
> Signed-off-by: Damien Lespiau
> ---
> framework/summary.py | 36 ++--
> 1 file changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/framework/summary.py b/framework/summary.py
> index 8fbe2a8..c42ee03 100644
> --- a/framework/summary.py
> +++ b/framework/summary.py
> @@ -38,6 +38,38 @@ __all__ = [
> ]
>
>
> +INTERVALS = (1, 60, 3600, 86400, 604800, 2419200, 29030400)
> +NAMES = ('s', 'min', 'hr', 'day', 'week', 'month', 'year')
> +
> +# Gives a human readable elapsed time
> +# @amount is a string with a number of seconds
> +def humanize_time(amount):
> +result = []
> +
> +if amount == 'None':
> +return 'None'
the python idiom is 'if not amount: return None'
> +
> +amount_f = float(amount)
> +if (amount_f < 1):
> +amount_ms = amount_f * 1000
> +if amount_ms < 1:
> +return "< 1ms"
> +return "%.1fms" % amount_ms
> +
> +# if < 10s, consider ms are important
> +if amount_f < 10:
> +return "%.03fs" % amount_f
> +
> +amount = int(amount_f)
> +
> +for i in range(len(NAMES) - 1, -1, -1):
in python2 avoid range, use xrange instead (xrange is range's lazy cousin) in
python3 range is xrange.
> + a = amount / INTERVALS[i]
> + if a > 0:
> + result.append("%d%s" % (a, NAMES[i]))
> + amount -= a * INTERVALS[i]
> +
> +return " ".join(result)
> +
on a more practicle note, why roll all of this instead of just using
datetime.timedelta?
> class HTMLIndex(list):
> """
> Builds HTML output to be passed to the index mako template, which will
> be @@ -420,7 +452,7 @@ class Summary:
>
> with open(path.join(destination, each.name, "index.html"), 'w')
> as out: out.write(testindex.render(name=each.name,
> - time=each.time_elapsed,
> +
> time=humanize_time(each.time_elapsed), options=each.options,
> glxinfo=each.glxinfo,
> lspci=each.lspci))
> @@ -447,7 +479,7 @@ class Summary:
> # disapear at somepoint
> env=value.get('environment', None),
> returncode=value.get('returncode', 'None'),
> -time=value.get('time', 'None'),
> +time=humanize_time(value.get('time', 'None')),
> info=value.get('info', 'None'),
> traceback=value.get('traceback', 'None'),
> command=value.get('command', 'None'),
signature.asc
Description: This is a digitally signed message part.
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
[Piglit] [PATCH] framework: Dump the result of 'uname -a' in the report
Signed-off-by: Damien Lespiau
---
framework/core.py | 3 +++
framework/summary.py| 1 +
templates/testrun_info.mako | 6 ++
3 files changed, 10 insertions(+)
diff --git a/framework/core.py b/framework/core.py
index e0fe46c..e0b49f8 100644
--- a/framework/core.py
+++ b/framework/core.py
@@ -293,11 +293,13 @@ class TestrunResult:
self.serialized_keys = ['options',
'name',
'tests',
+'uname',
'wglinfo',
'glxinfo',
'lspci',
'time_elapsed']
self.name = None
+self.uname = None
self.glxinfo = None
self.lspci = None
self.time_elapsed = None
@@ -432,6 +434,7 @@ class Environment:
else:
result['glxinfo'] = self.run('glxinfo')
if system == 'Linux':
+result['uname'] = self.run(['uname', '-a'])
result['lspci'] = self.run('lspci')
return result
diff --git a/framework/summary.py b/framework/summary.py
index a85353a..13596ea 100644
--- a/framework/summary.py
+++ b/framework/summary.py
@@ -458,6 +458,7 @@ class Summary:
out.write(testindex.render(name=each.name,
time=humanize_time(each.time_elapsed),
options=each.options,
+ uname=each.uname,
glxinfo=each.glxinfo,
lspci=each.lspci))
diff --git a/templates/testrun_info.mako b/templates/testrun_info.mako
index e6e00b3..6ff1f44 100644
--- a/templates/testrun_info.mako
+++ b/templates/testrun_info.mako
@@ -30,6 +30,12 @@
${options}
+uname -a
+
+ ${uname}
+
+
+
lspci
${lspci}
--
1.8.3.1
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
[Piglit] [PATCH] framework: Humanize time values in the HTML report
It's a bit hard to parse raw seconds, so make those time values easier
to read while trying to preserve roughly enough relevant precision to be
useful.
It gives strings like:
22.4ms
7.798s
42.3s
7min 25s
...
v2: Remove support for days, weeks, months and years, surely no test
should be that long! (Daniel Vetter)
Display 1 decimal if the duration is < 60s (Daniel Vetter)
Signed-off-by: Damien Lespiau
Reviewed-by: Daniel Vetter
---
framework/summary.py | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/framework/summary.py b/framework/summary.py
index 8fbe2a8..a85353a 100644
--- a/framework/summary.py
+++ b/framework/summary.py
@@ -38,6 +38,42 @@ __all__ = [
]
+INTERVALS = (1, 60, 3600)
+NAMES = ('s', 'min', 'hr')
+
+# Gives a human readable elapsed time
+# @amount is a string with a number of seconds
+def humanize_time(amount):
+result = []
+
+if amount == 'None':
+return 'None'
+
+amount_f = float(amount)
+if (amount_f < 1):
+amount_ms = amount_f * 1000
+if amount_ms < 1:
+return "< 1ms"
+return "%.1fms" % amount_ms
+
+# if < 10s, consider ms are important
+if amount_f < 10:
+return "%.03fs" % amount_f
+
+# still display 1 decimal when < 60s
+if amount_f < 60:
+return "%.01fs" % amount_f
+
+amount = int(amount_f)
+
+for i in range(len(NAMES) - 1, -1, -1):
+ a = amount / INTERVALS[i]
+ if a > 0:
+ result.append("%d%s" % (a, NAMES[i]))
+ amount -= a * INTERVALS[i]
+
+return " ".join(result)
+
class HTMLIndex(list):
"""
Builds HTML output to be passed to the index mako template, which will be
@@ -420,7 +456,7 @@ class Summary:
with open(path.join(destination, each.name, "index.html"), 'w') as
out:
out.write(testindex.render(name=each.name,
- time=each.time_elapsed,
+
time=humanize_time(each.time_elapsed),
options=each.options,
glxinfo=each.glxinfo,
lspci=each.lspci))
@@ -447,7 +483,7 @@ class Summary:
# disapear at somepoint
env=value.get('environment', None),
returncode=value.get('returncode', 'None'),
-time=value.get('time', 'None'),
+time=humanize_time(value.get('time', 'None')),
info=value.get('info', 'None'),
traceback=value.get('traceback', 'None'),
command=value.get('command', 'None'),
--
1.8.3.1
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH] framework: Humanize time values in the HTML report
On Fri, Nov 15, 2013 at 09:06:51AM +, Damien Lespiau wrote:
> It's a bit hard to parse raw seconds, so make those time values easier
> to read while trying to preserve roughly enough relevant precision to be
> useful.
>
> It gives strings like:
>
> 22.4ms
> 7.798s
> 42s
> 7min 25s
> ...
>
> Signed-off-by: Damien Lespiau
> ---
> framework/summary.py | 36 ++--
> 1 file changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/framework/summary.py b/framework/summary.py
> index 8fbe2a8..c42ee03 100644
> --- a/framework/summary.py
> +++ b/framework/summary.py
> @@ -38,6 +38,38 @@ __all__ = [
> ]
>
>
> +INTERVALS = (1, 60, 3600, 86400, 604800, 2419200, 29030400)
> +NAMES = ('s', 'min', 'hr', 'day', 'week', 'month', 'year')
I'd kill everything above hr, at least I didn't bother checking them ;-)
> +
> +# Gives a human readable elapsed time
> +# @amount is a string with a number of seconds
> +def humanize_time(amount):
> +result = []
> +
> +if amount == 'None':
> +return 'None'
> +
> +amount_f = float(amount)
> +if (amount_f < 1):
> +amount_ms = amount_f * 1000
> +if amount_ms < 1:
> +return "< 1ms"
> +return "%.1fms" % amount_ms
> +
> +# if < 10s, consider ms are important
> +if amount_f < 10:
> +return "%.03fs" % amount_f
Since you've gone overboard so much, what about %.01fs if it's less than
60 s?
With or without any of these bikesheds:
Reviewed-by: Daniel Vetter
> +
> +amount = int(amount_f)
> +
> +for i in range(len(NAMES) - 1, -1, -1):
> + a = amount / INTERVALS[i]
> + if a > 0:
> + result.append("%d%s" % (a, NAMES[i]))
> + amount -= a * INTERVALS[i]
> +
> +return " ".join(result)
> +
> class HTMLIndex(list):
> """
> Builds HTML output to be passed to the index mako template, which will be
> @@ -420,7 +452,7 @@ class Summary:
>
> with open(path.join(destination, each.name, "index.html"), 'w')
> as out:
> out.write(testindex.render(name=each.name,
> - time=each.time_elapsed,
> +
> time=humanize_time(each.time_elapsed),
> options=each.options,
> glxinfo=each.glxinfo,
> lspci=each.lspci))
> @@ -447,7 +479,7 @@ class Summary:
> # disapear at somepoint
> env=value.get('environment', None),
> returncode=value.get('returncode', 'None'),
> -time=value.get('time', 'None'),
> +time=humanize_time(value.get('time', 'None')),
> info=value.get('info', 'None'),
> traceback=value.get('traceback', 'None'),
> command=value.get('command', 'None'),
> --
> 1.8.3.1
>
> ___
> Piglit mailing list
> Piglit@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/piglit
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
Re: [Piglit] [PATCH 3/6] dmesg: setup dmesg to be able to mark a test warn or fail
On Thu, Nov 14, 2013 at 10:35:03AM -0800, Dylan Baker wrote: > On Thursday, November 14, 2013 05:34:38 PM Daniel Vetter wrote: > > On Thu, Nov 14, 2013 at 08:04:20AM -0800, Dylan Baker wrote: > > > On Thursday, November 14, 2013 02:52:41 PM Daniel Vetter wrote: > > > > On Tue, Nov 12, 2013 at 07:54:01AM -0800, Dylan Baker wrote: > > > > > This gives the dmesg class lists of statuses that will make a test a > > > > > warn or a fail, it includes a few basic checks, namely i915 errors and > > > > > that tests have not segfaulted. > > > > > > > > > > Signed-off-by: Dylan Baker > > > > > --- > > > > > > > > > > framework/dmesg.py| 36 > > > > > framework/exectest.py | 22 +++--- > > > > > 2 files changed, 47 insertions(+), 11 deletions(-) > > > > > > > > > > diff --git a/framework/dmesg.py b/framework/dmesg.py > > > > > index 9a23c14..edbea88 100644 > > > > > --- a/framework/dmesg.py > > > > > +++ b/framework/dmesg.py > > > > > @@ -22,6 +22,7 @@ > > > > > > > > > > """ Module implementing classes for reading posix dmesg """ > > > > > > > > > > import os > > > > > > > > > > +import re > > > > > > > > > > import subprocess > > > > > from threads import synchronized_self > > > > > > > > > > @@ -29,8 +30,10 @@ __all__ = ['Dmesg'] > > > > > > > > > > # plain text list of statuses to be considered either a warn or a > > > > > fail, > > > > > any > > > > > # statuses not on this list will simply be ignored. > > > > > > > > > > -WARN_STATUSES = [] > > > > > -FAIL_STATUSES = [] > > > > > +WARN_STATUSES = ['segfault'] > > > > > +FAIL_STATUSES = ['\[drm:.*\] \*ERROR\*', > > > > > + '\[drm\] stuck on [a-zA-Z]* ring', > > > > > + '\[drm\] GPU crash dump saved'] > > > > > > > > I think now that we filter out all the info/debug noise maybe we could > > > > go > > > > the other direction and blacklist a few of the remaining things from the > > > > core kernel we don't care about. E.g. > > > > > > > > [ 3867.022895] gem_evict_every (2671) used greatest stack depth: 2216 > > > > bytes > > > > left > > > > > > > > is a warn level message, but I don't care one bit about it (as long as > > > > it > > > > doesn't approach 0). But there's other warn level stuff which is fairly > > > > interesting. > > > > > > > > Just something to throw out there, I'm not sure what the best way would > > > > be > > > > to integrate dmesg reporting for piglit in general. > > > > -Daniel > > > > > > My personal problem with the dmesg code we have now (and with *just* > > > blacklisting) is that I have an alps touchpad, it spams dmesg about 10 > > > times a minute, so I can't use dmesg reporting because of the massive > > > number of false positives; we could use some combination of blacklisting > > > and whitelisting however. > > > > That sounds like we need a piglit cmdline option to supply a regex to > > filter out crap like that ... Or is the alps touchpad driver so bad > > there's not even a regex we could match it all against? > > -Daniel > > My concern is more that trying to filter out things we don't want seems like > an uphill battle that will become expensive quickly. First it's my touchpad, > then it's so and so's usb, and so on. I'm giong to ask some of the mesa guys > here in the office to weigh in with their thoughts, since they're all around > today, snice I'm basing interest on one developer's opinions. That's kinda what the cmdline would be for, to get rid of machine-specific stuff like your touchpad. I'm retesting igt on all the machines I have here right now, and thus far the stack usage warning is the only offender I've seend which wasn't a genuine issue. But yeah, more input should definitely help. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
[Piglit] [PATCH] framework: Humanize time values in the HTML report
It's a bit hard to parse raw seconds, so make those time values easier
to read while trying to preserve roughly enough relevant precision to be
useful.
It gives strings like:
22.4ms
7.798s
42s
7min 25s
...
Signed-off-by: Damien Lespiau
---
framework/summary.py | 36 ++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/framework/summary.py b/framework/summary.py
index 8fbe2a8..c42ee03 100644
--- a/framework/summary.py
+++ b/framework/summary.py
@@ -38,6 +38,38 @@ __all__ = [
]
+INTERVALS = (1, 60, 3600, 86400, 604800, 2419200, 29030400)
+NAMES = ('s', 'min', 'hr', 'day', 'week', 'month', 'year')
+
+# Gives a human readable elapsed time
+# @amount is a string with a number of seconds
+def humanize_time(amount):
+result = []
+
+if amount == 'None':
+return 'None'
+
+amount_f = float(amount)
+if (amount_f < 1):
+amount_ms = amount_f * 1000
+if amount_ms < 1:
+return "< 1ms"
+return "%.1fms" % amount_ms
+
+# if < 10s, consider ms are important
+if amount_f < 10:
+return "%.03fs" % amount_f
+
+amount = int(amount_f)
+
+for i in range(len(NAMES) - 1, -1, -1):
+ a = amount / INTERVALS[i]
+ if a > 0:
+ result.append("%d%s" % (a, NAMES[i]))
+ amount -= a * INTERVALS[i]
+
+return " ".join(result)
+
class HTMLIndex(list):
"""
Builds HTML output to be passed to the index mako template, which will be
@@ -420,7 +452,7 @@ class Summary:
with open(path.join(destination, each.name, "index.html"), 'w') as
out:
out.write(testindex.render(name=each.name,
- time=each.time_elapsed,
+
time=humanize_time(each.time_elapsed),
options=each.options,
glxinfo=each.glxinfo,
lspci=each.lspci))
@@ -447,7 +479,7 @@ class Summary:
# disapear at somepoint
env=value.get('environment', None),
returncode=value.get('returncode', 'None'),
-time=value.get('time', 'None'),
+time=humanize_time(value.get('time', 'None')),
info=value.get('info', 'None'),
traceback=value.get('traceback', 'None'),
command=value.get('command', 'None'),
--
1.8.3.1
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
