Am 31.10.2013 20:34, schrieb Ian Romanick:
> On 10/28/2013 04:53 PM, Zack Rusin wrote:
>> Increase the subpixel precision to 8 bits. This requires
>> changing some of the code to 64 bits to avoid overflows.
>
> I'm not that familiar with this test. Does this change make this test
> more strict?
sts/util/piglit-util-gl.h
> @@ -203,6 +203,7 @@ GLfloat *piglit_rgbw_image(GLenum internalFormat, int w,
> int h,
> GLuint piglit_rgbw_texture(GLenum internalFormat, int w, int h, GLboolean
> mip,
> GLboolean alpha, GLenum basetype);
> GLuint piglit_depth_te
Am 18.09.2014 16:16, schrieb Brian Paul:
> Reviewed-by: Brian Paul
>
> Just a minor suggestion below (in 2 places).
>
>
> On 09/18/2014 08:09 AM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> The test takes ages (somewhere in the order of an
Am 19.09.2014 17:12, schrieb Brian Paul:
> So that llvmpipe can run in a reasonable amount of time.
> ---
> tests/shaders/fp-indirections2.c |5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/tests/shaders/fp-indirections2.c
> b/tests/shaders/fp-indirections2.c
> in
One nitpick otherwise looks good to me.
Reviewed-by: Roland Scheidegger
Am 01.12.2014 um 16:57 schrieb jfons...@vmware.com:
> From: José Fonseca
>
> Adapt the primitive-id-no-gs-first test case to first provoking vertex
> convention, exposing a bug in llvmpipe.
> ---
&
ping?
Am 06.12.2014 um 05:20 schrieb srol...@vmware.com:
> From: Roland Scheidegger
>
> Just using tri strip instead of tri fan.
> Exposing more bugs in llvmpipe/draw...
> ---
> ...imitive-id-no-gs-strip-first-vertex.shader_test | 62
> ++
> .../e
LGTM, though the test could even be more mean by trying different
internal formats too.
This is indeed crazy stuff, just an unfortunate side effect of
specifying all faces individually. (Makes you wonder why GL didn't use
TexImage3D for this just like it does for cube map arrays, but I guess
there
Looks good to me, just a minor nit below. Does not quite check all prim
types as it misses the adjacency ones but I guess that would require
some more strict gl version check...
Reviewed-by: Roland Scheidegger
Am 13.01.2015 um 17:57 schrieb Brian Paul:
> None of the other provoking vertex te
Am 18.02.2015 um 14:36 schrieb Jose Fonseca:
> Although the non-standard GCC syntax has some nice properties, for most
> practical cases the standard C99 syntax is perfectly fine. Particuarly
> for printf-like macros, which pretty much account for most the uses of
> variadic macros in piglit.
>
>
"{\n"
> - " gl_FragColor = gl_Color;\n"
> + " gl_FragColor = color * color_scale;\n"
> "}\n";
>
> #define NUM_SQUARES 4
>
This looks good to me, the test comment says though it's the same as
rendering.c except for the persistent mapped ubos which is no longer
quite true.
Reviewed-by: Roland Scheidegger
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
rcolor'],
> +adder(['texwrap', target, 'GL_RGBA8', 'bordercolor'],
>'texwrap {} bordercolor'.format(target))
> -adder(['texwrap', 'GL_RGBA8', 'proj'], 'texwrap {} proj'.format(target))
ile in c89 mode so far without this being an explicit requirement.
But I don't have anything against updating that (implicit?) policy to
c99 (minus whatever msvc still doesn't support...), albeit it's
certainly not me who should say what the requirements need to be.
Reviewed-by: Roland Scheidegger
Roland
___
Piglit mailing list
Piglit@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/piglit
Ah yes, I'll add that before commiting.
Roland
Am 23.12.2015 um 02:04 schrieb Dylan Baker:
> You'll need to add this to all.py
>
> On Tue, Dec 22, 2015 at 10:05 AM, <mailto:srol...@vmware.com>> wrote:
>
> From: Roland Scheidegger <mailto:srol.
Am 24.12.2015 um 01:34 schrieb baker.dyla...@gmail.com:
> From: Dylan Baker
>
> This wasn't added to all.py.
>
> cc: Roland Scheidegger
> Signed-off-by: Dylan Baker
> ---
> tests/all.py | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tests
Am 04.01.2016 um 20:45 schrieb Jose Fonseca:
> On 22/12/15 18:05, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> This test is quite mean to mesa's draw pipe. llvmpipe/softpipe fail
>> even if
>> front and back fill mode is the same (for point
Oops just forget the changes on the quad-invariance test (this is just
what I used to prove the same issue on "real" hw).
Am 09.01.2016 um 02:12 schrieb srol...@vmware.com:
> From: Roland Scheidegger
>
> The rect halves comparison is in fact not valid in general. The reason
Am 09.01.2016 um 04:09 schrieb Ian Romanick:
> On 01/08/2016 05:12 PM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> The rect halves comparison is in fact not valid in general. The reason is
>> that
>> the same geometry does not have the same pre
ping?
Am 09.01.2016 um 05:40 schrieb srol...@vmware.com:
> From: Roland Scheidegger
>
> The rect halves comparison is in fact not valid in general. The reason is that
> the same geometry does not have the same precision even if it it just shifted
> by some fixed amount in one dir
Am 13.01.2016 um 03:32 schrieb Ilia Mirkin:
> On Tue, Jan 12, 2016 at 8:07 PM, wrote:
>> From: Roland Scheidegger
>>
>> At least mesa/st fails this right now (always uses the initial format for mip
>> gen).
>>
>> v2: don't use piglit_display (not actu
Am 05.02.2016 um 01:55 schrieb Matt Turner:
> On Thu, Feb 4, 2016 at 10:50 AM, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> This is a subset of the generated tests which are known to fail
>> on everything except CPU emulation (AFAIK).
>> ---
>
> This is really awful. Committing a generated test
Am 05.02.2016 um 15:44 schrieb Marek Olšák:
> On Fri, Feb 5, 2016 at 10:57 AM, Marek Olšák wrote:
>> On Fri, Feb 5, 2016 at 1:55 AM, Matt Turner wrote:
>>> On Thu, Feb 4, 2016 at 10:50 AM, Marek Olšák wrote:
From: Marek Olšák
This is a subset of the generated tests which are know
Am 05.02.2016 um 16:08 schrieb Marek Olšák:
> On Fri, Feb 5, 2016 at 3:56 PM, Roland Scheidegger wrote:
>> Am 05.02.2016 um 15:44 schrieb Marek Olšák:
>>> On Fri, Feb 5, 2016 at 10:57 AM, Marek Olšák wrote:
>>>> On Fri, Feb 5, 2016 at 1:55 AM, Matt Turner wrote:
&
Am 05.02.2016 um 17:04 schrieb Marek Olšák:
> On Fri, Feb 5, 2016 at 4:48 PM, Roland Scheidegger wrote:
>> Am 05.02.2016 um 16:08 schrieb Marek Olšák:
>>> On Fri, Feb 5, 2016 at 3:56 PM, Roland Scheidegger
>>> wrote:
>>>> Am 05.02.2016 um 15:44 schrieb Ma
rn(false);
> + if (!check_test_pattern(0, half_h))
> + pass = false;
> +
> + /* Normal GL origin / Draw in lower-right screen quadrant */
> + glViewport(half_w, 0, half_w, half_h);
> + draw_test_pattern(false);
> + if (!check_test_pattern(half_w, 0))
eturn PIGLIT_PASS;
> +}
> +
> +
> +void
> +piglit_init(int argc, char **argv)
> +{
> + glReadBuffer(GL_FRONT);
> +
> + if (!piglit_check_gl_error(GL_NO_ERROR)) {
> + piglit_report_result(PIGLIT_FAIL);
> + }
> +
> + piglit_report_result(PIGLIT_PASS);
> +}
>
Is that a new most simple piglit test ;-).
Reviewed-by: Roland Scheidegger
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit
Am 19.04.2016 um 18:41 schrieb Jose Fonseca:
> On 19/04/16 01:32, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> The spec doesn't really say this should work in older versions. It was
>> first
>> added in glsl 4.30, mentioning it was forgotten
Am 19.04.2016 um 19:27 schrieb Jose Fonseca:
> On 19/04/16 18:21, Roland Scheidegger wrote:
>> Am 19.04.2016 um 18:41 schrieb Jose Fonseca:
>>> On 19/04/16 01:32, srol...@vmware.com wrote:
>>>> From: Roland Scheidegger
>>>>
>>>> The spec doe
Am 09.09.2016 um 23:32 schrieb Adam Jackson:
> On Fri, 2016-09-09 at 12:09 -0700, Ian Romanick wrote:
>
>> 16 *gigabytes*? Why? That has to indicate a bug somewhere...
>> possibly a leak in the test?
>
> I suspect more likely a leak in llvmpipe, or in how it's driving llvm.
> You're going to en
r would
need to translate the alpha_to_coverage bit away, otherwise it's
impossible for a driver to implement both gl and d3d10 behavior.
Reviewed-by: Roland Scheidegger
Am 15.09.2016 um 22:16 schrieb Brian Paul:
> Currently fails with llvmpipe. Fragments with alpha <= 0.5 are discarded.
>
Am 30.10.2012 00:22, schrieb Brian Paul:
> On 10/29/2012 05:05 PM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> Make sure clipping is needed sometimes, and more often use small index
>> counts,
>> to expose issues and excercise more paths in mesa
Am 30.10.2012 20:01, schrieb Ian Romanick:
> On 10/29/2012 05:34 PM, Roland Scheidegger wrote:
>> Am 30.10.2012 00:22, schrieb Brian Paul:
>>> On 10/29/2012 05:05 PM, srol...@vmware.com wrote:
>>>> From: Roland Scheidegger
>>>>
>>>> Make sure
Am 27.11.2012 08:25, schrieb Eric Anholt:
> srol...@vmware.com writes:
>
>> From: Roland Scheidegger
>>
>> core GL specifies out-of-bound accesses have undefined behavior,
>> which includes crashes.
>> Crashes are very much undesired, but ARB_robustness st
Am 27.11.2012 22:36, schrieb Eric Anholt:
> srol...@vmware.com writes:
>
>> From: Roland Scheidegger
>>
>> core GL specifies out-of-bound accesses have undefined behavior,
>> which includes crashes.
>> Crashes are very much undesired, but ARB_robustness st
ol...@vmware.com writes:
>
>> From: Roland Scheidegger
>>
>> core GL specifies out-of-bound texel fetches return undefined results,
>> except in a robust context with ARB_robust_buffer_access_behavior supported
>> (which is core in 4.3), in which case texel fetch will
Am 05.03.2013 17:05, schrieb Brian Paul:
> On 03/05/2013 08:37 AM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> This is pretty rough and doesn't really test all that much (just
>> textureOffsetLod, but there's other texturing functions with off
Am 05.03.2013 19:41, schrieb Brian Paul:
> On 03/05/2013 11:03 AM, Roland Scheidegger wrote:
>> Am 05.03.2013 17:05, schrieb Brian Paul:
>>> On 03/05/2013 08:37 AM, srol...@vmware.com wrote:
>>>> From: Roland Scheidegger
>>>>
>>>> This is pr
Please disregard this sent the wrong stuff...
Am 22.03.2013 23:21, schrieb srol...@vmware.com:
> From: Roland Scheidegger
>
> This is pretty rough and doesn't really test all that much (just
> textureOffsetLod, but there's other texturing functions with offsets),
> do
Am 23.03.2013 01:41, schrieb Ian Romanick:
> On 03/22/2013 03:28 PM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> Similar to glsl-fs-main-return (and glsl-vs-main-return), this is testing
>> using return in main. Contrary to the these other tests, this h
Am 04.04.2013 01:55, schrieb Brian Paul:
> On 04/03/2013 05:14 PM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> Similar to arb_shader_texture_lod-texgrad, but using cube maps instead.
>> Given the somewhat undefined behavior of explicit gradients with cub
Am 04.04.2013 17:48, schrieb Brian Paul:
> On 04/04/2013 09:33 AM, Roland Scheidegger wrote:
>> Am 04.04.2013 01:55, schrieb Brian Paul:
>>> On 04/03/2013 05:14 PM, srol...@vmware.com wrote:
>>>> From: Roland Scheidegger
>>>>
>>>> Similar
Reviewed-by: Roland Scheidegger
Am 05.05.2017 um 08:47 schrieb Neha Bhende:
> piglit_linear_to_srgb() returns float values in [0,1]. The test was
> comparing it against integer values in [0,255]. This is why test was
> failing.
>
> Also, fix the overall test pass/fail logic.
&
Am 04.08.2017 um 16:43 schrieb Brian Paul:
> On 08/04/2017 08:32 AM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> I believe the sole reason alpha-to-one exists at all is that it can be
>> used together with alpha-to-coverage (otherwise why not just outpu
ly take
into account that the samples which get written thanks to
coverage-to-alpha also had their alpha values changed to 1.0, but I
could be wrong and maybe it is correct after all...
In any case,
Reviewed-by: Roland Scheidegger
Am 04.08.2017 um 19:03 schrieb Brian Paul:
> Alpha-to-one onl
7 um 19:28 schrieb Brian Paul:
> It passes here for me w/ NVIDIA's driver but I'll hold off on this until
> I can take a closer look.
>
> -Brina
>
> On 08/04/2017 11:11 AM, Roland Scheidegger wrote:
>> I think should mention that the reference probably isn't quite
Thanks for fixing this.
Reviewed-by: Roland Scheidegger
Am 16.08.2017 um 05:30 schrieb Brian Paul:
> Skip testing MSAA textures if GL_MAX_SAMPLES = 0.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102123
> ---
> tests/spec/gl-3.2/layered-rendering/framebuffe
ping?
Am 09.09.2017 um 07:31 schrieb srol...@vmware.com:
> From: Roland Scheidegger
>
> Tolerance was added for the tests a while ago, but it looks like it was
> forgotten for the nearest_biased test (the nearest one has it).
> Also, for the linear test, add tolerance too when co
Am 12.10.2017 um 21:19 schrieb Brian Paul:
> On 10/12/2017 12:11 PM, Jose Fonseca wrote:
>> On 12/10/17 17:51, Brian Paul wrote:
>>> On 10/12/2017 08:04 AM, Jose Fonseca wrote:
The intent here was not so much to match the piglti MSVC build, but
apps
build by MSVC in general.
>>>
Ping?
Am 09.11.2017 um 19:11 schrieb srol...@vmware.com:
> From: Roland Scheidegger
>
> We expect non-nan results for these (according to d3d10 rules, and at least
> for min/max, also according to ieee rules). The tests will not actually fail
> with other results (since GL's
Am 22.11.2017 um 19:45 schrieb Eric Anholt:
> srol...@vmware.com writes:
>
>> From: Roland Scheidegger
>>
>> The existing fbo-blending-formats test is mostly useless for anything but
>> unorm formats, since it does not test any values outside [0,1] (neither
Am 22.11.2017 um 20:17 schrieb Roland Scheidegger:
> Am 22.11.2017 um 19:45 schrieb Eric Anholt:
>> srol...@vmware.com writes:
>>
>>> From: Roland Scheidegger
>>>
>>> The existing fbo-blending-formats test is mostly useless for anything but
>>&g
Am 22.11.2017 um 20:46 schrieb Ilia Mirkin:
> On Wed, Nov 22, 2017 at 2:19 PM, Roland Scheidegger
> wrote:
>> Am 22.11.2017 um 20:17 schrieb Roland Scheidegger:
>>> Am 22.11.2017 um 19:45 schrieb Eric Anholt:
>>>> srol...@vmware.com writes:
>>>>
&g
TEXTURE_SAMPLES, &max_samples);
> +if (max_samples < 1) {
> + printf("GL_MAX_COLOR_TEXTURE_SAMPLES must be at least one\n");
> + piglit_report_result(PIGLIT_FAIL);
> +}
Do you want to use the maximum possible or restrict that to something
smaller (in case the value
I'm pretty sure that helps llvmpipe too.
Reviewed-by: Roland Scheidegger
Am 26.12.2017 um 07:55 schrieb Kenneth Graunke:
> OpenGL defines two equations for converting from signed-normalized
> to floating point data. These are:
>
> f = (2c + 1)/(2^b - 1)
Reviewed-by: Roland Scheidegger
Am 24.12.2017 um 23:41 schrieb Brian Paul:
> Create the largest possible 2D GL_RGBA_32F multisampled texture, load it
> with known values the read it back and see if the values match up.
>
> The --array option runs the test with a 2D texture array i
Am 03.01.2018 um 04:40 schrieb Ilia Mirkin:
> Reviewed-by: Ilia Mirkin
>
> On Tue, Jan 2, 2018 at 9:27 PM, wrote:
>> + static const char *fs_source =
>> + "#version 150\n"
>> + "#extension GL_ARB_gpu_shader5: require\n"
>> + "uniform samplerBuffer
ure-size test should be added to all.py (in
> multiple places).
>
> Other than that, series is
> Reviewed-by: Fabian Bieler
>
> On 2018-01-01 06:41, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> This is a problem of all texturing tests, they cannot
ping?
Am 08.01.2018 um 01:20 schrieb srol...@vmware.com:
> From: Roland Scheidegger
>
> -128 and -127 represent exactly the same value (-1.0) for snorm8 values,
> as do -32768/-32767 for snorm16. Therefore it seems quite reasonable that an
> implementation would return the other
Am 11.01.2018 um 23:08 schrieb Brian Paul:
> On 01/11/2018 02:45 PM, Roland Scheidegger wrote:
>> ping?
>>
>> Am 08.01.2018 um 01:20 schrieb srol...@vmware.com:
>>> From: Roland Scheidegger
>>>
>>> -128 and -127 represent exactly the same value (
st(GLenum mat, bool set_all)
> +{
> + GLuint list;
> +
> + list = glGenLists(1);
> + glNewList(list, GL_COMPILE);
> +
> + /*
> + * Draw tri strip drawing two quads- left=red, right=green.
whitespace before "-" ?
Ahhh materials. Quite
That should help llvmpipe quite a bit...
Albeit 1% doesn't sound like it would give a lot of coverage, maybe a
bit more (5% or so) would still cut down the time significantly while
having less risk of missing failures?
Either way,
for 1-2/3
Reviewed-by: Roland Scheidegger
Am 17.01.2018 um
C I
thought about trying to work around it in llvmpipe code, but there was
no trivial solution (for not just avoiding the hang but still correctly
rendering) and I didn't care enough about that particular llvm version,
even more so since it was fixed in the stable branch...)
But in any case if yo
Am 18.01.2018 um 21:04 schrieb Brian Paul:
> On 01/18/2018 12:38 PM, Roland Scheidegger wrote:
>> Am 18.01.2018 um 20:07 schrieb Brian Paul:
>>> To avoid an infinite loop. See code comments for details.
>>> ---
>>> tests/spec/gl-1.0/blend.c | 39 +++
Am 19.01.2018 um 06:35 schrieb Eric Anholt:
> Brian Paul writes:
>
>> On 01/18/2018 01:27 PM, Eric Anholt wrote:
>>> Brian Paul writes:
>>>
To avoid an infinite loop. See code comments for details.
>>>
>>> Skipping a failing test and returning pass is wrong to me.
>>
>> It's not ideal. Bu
Am 27.01.2018 um 02:00 schrieb srol...@vmware.com:
> From: Roland Scheidegger
>
> The test fed the equivalent_pname into the get_unsupported_response()
> function, which led to nonsense logged errors as this only recognizes
> the original pnames.
> Refactor pname/equivalent_pn
Am 05.02.2018 um 17:12 schrieb Brian Paul:
> On 02/04/2018 04:03 PM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> The spec says with msaa disabled gl_SampleMaskIn is always 1.
>> This is not particularly related to arb_sample_shading, but drivers may
Am 24.09.2018 um 15:56 schrieb Ian Romanick:
> From: Ian Romanick
>
> As people dig up other games, we can (and should) easily add them.
>
> Signed-off-by: Ian Romanick
> Cc: Federico Dossena
> Cc: Roland Scheidegger
> ---
> tests/general/CMakeLists.gl.txt
Looks good to me.
For the series:
Reviewed-by: Roland Scheidegger
Am 13.03.19 um 15:16 schrieb Jose Fonseca:
> With GitLab is now much easier to setup.
> ---
> appveyor.yml | 22 --
> 1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --gi
67 matches
Mail list logo
