---
.../component-layout/fs-out-array.shader_test | 36 ++
.../fs-out-overlap-array.shader_test | 36 ++
.../component-layout/fs-out-overlap4.shader_test | 35 +
.../fs-out-type-mismatch-array.shader_test | 36
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 actually drawing anything), suggested
>> by Ilia
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 actually drawing anything), suggested
> by Ilia Mirkin.
> ---
> tests/all.py
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 actually drawing anything), suggested
by Ilia Mirkin.
---
tests/all.py | 1 +
tests/spec/arb_texture_view/CMakeLists.
On Tue, Jan 12, 2016 at 7:20 PM, wrote:
> From: Roland Scheidegger
>
> At least mesa/st fails this right now (always uses the initial format for mip
> gen).
> ---
> tests/all.py | 1 +
> tests/spec/arb_texture_view/CMakeLists.gl.txt | 1 +
> tests/spec/arb_t
From: Roland Scheidegger
At least mesa/st fails this right now (always uses the initial format for mip
gen).
---
tests/all.py | 1 +
tests/spec/arb_texture_view/CMakeLists.gl.txt | 1 +
tests/spec/arb_texture_view/mipgen.c | 102 +
That is the plan I think? Timothy will merge Ian's scripts, and then we can
rebase cleanups and send them out for review?
On Tue, Jan 12, 2016 at 3:09 PM, Ilia Mirkin wrote:
> My fixes are one-liners (might just be one, I forget). At this point I
> would very much like to see *anything* checked
My fixes are one-liners (might just be one, I forget). At this point I
would very much like to see *anything* checked in, and we can improve
from there.
On Tue, Jan 12, 2016 at 6:04 PM, Dylan Baker wrote:
> That sounds like a plan. Would you like to get Ian's original scripts
> merged, and I'll u
That sounds like a plan. Would you like to get Ian's original scripts
merged, and I'll update the cleanups I have for his scripts and send them
out?
Dylan
On Tue, Jan 12, 2016 at 2:41 PM, Timothy Arceri
wrote:
> On Tue, 2015-11-10 at 16:46 -0800, Dylan Baker wrote:
> > Since gravy is so delicio
On Tue, 2015-11-10 at 16:46 -0800, Dylan Baker wrote:
> Since gravy is so delicious,
>
> https://github.com/dcbaker/piglit.git wip/ubo-fuzzer
>
> bin/piglit run ubo-fuzzer output
>
> Obviously it's not at all feature complete, it's more proof of
> concept
> than anything else, but gravy.
Hi Dyl
I hadn't pushed any changes here, and noticed this was still outstanding
while doing some other work. Thanks for doing this work.
On Tue, Jan 12, 2016 at 2:59 AM, Jose Fonseca wrote:
> Thanks. I wasn't sure if your changes already had taken care of this. I've
> pushed it now.
>
> Jose
>
> On 12/
EXT_multisampled_render_to_texture allows you to bind a singlesampled
texture to the color attachment of a multisampled framebuffer object.
Rendering is multisampled and the multisample data is implicitly
resolved and invalidated when texturing.
The test renders a ground truth image by drawing a s
Thank you Ian for the review and helpful comments.
My apologies for not getting the reply done before the holidays. To keep the
mail short I have not replied to any comments you had that I just fixed
according to your suggestions. So consider all that addressed.
>> [blitting from a multisampled
On 12/01/16 17:51, Roland Scheidegger wrote:
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 f
Reviewed-by: Ian Romanick
On 01/08/2016 08:40 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 precision even if it it just shifted
> by some fixed amount in one
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 direction.
> As an
Thanks. I wasn't sure if your changes already had taken care of this.
I've pushed it now.
Jose
On 12/01/16 00:08, Dylan Baker wrote:
reviewed-by: Dylan Baker mailto:baker.dyla...@gmail.com>>
On Tue, Dec 8, 2015 at 8:14 AM, Jose Fonseca mailto:jfons...@vmware.com>> wrote:
Exceptions were
---
.../ssbo-packed-layout-member-align.vert | 26 ++
.../ssbo-shared-layout-block-align.vert| 26 ++
.../ssbo-shared-layout-member-align.vert | 26 ++
.../align-layout/ssbo-std140-block-align.vert | 2
---
.../ssbo-block-align-not-power-of-two.vert | 26 ++
.../ssbo-member-align-not-power-of-two.vert| 26 ++
.../ubo-block-align-not-power-of-two.vert | 24
.../align-layout/ubo-block-align-zero.vert | 24
19 matches
Mail list logo
