Hi Nanley,
Could you explain the reasoning behind this patch? I can't find any
mention of needing to align to the square of the block size in the docs.
I think how it works is that on Skylake you can pick any alignment value
you want out of 4, 8 or 16 but for compressed textures that is counted
i
This function was trying to align the width and height to a multiple
of the block size for compressed textures. It was using align_w/h as a
shortcut to get the block size as up until Gen9 this always happens to
match. However in Gen9+ the alignment values are expressed as
multiples of the block siz
Ah, good catch. Looks good to me.
Reviewed-by: Neil Roberts
It seems a bit weird to use create_pbo=true at all for
glTexImage{1,2,3}D because in that case we are completely replacing the
texture. If the texture's buffer is busy instead of allocating a PBO we
might as well just directly all
Previously when glTexImage* is called it would attempt to create a
temporary PBO if the texture is busy in order to avoid blocking when
mapping the texture. This doesn't make much sense for glTexImage
because in that case we are completely replacing the texture anyway so
instead of allocating a PBO
Neil Roberts writes:
> It seems a bit weird to use create_pbo=true at all for
> glTexImage{1,2,3}D because in that case we are completely replacing
> the texture. If the texture's buffer is busy instead of allocating a
> PBO we might as well just directly allocate some ne
g
tests by hand after a reboot to see if they fail consistently.
Regards,
- Neil
Nanley Chery writes:
> Hey Neil,
>
> While this patch does fix FXT1, it also regresses 21 other Piglit tests on
> SKL.
>
> - Nanley
>
> On Thu, Jun 11, 2015 at 8:59 AM, Neil Roberts wrote:
&g
> On Fri, Jun 12, 2015 at 7:34 AM, Neil Roberts wrote:
>> The code was buggy anyway because it was checking whether the buffer
>> was busy before calling Driver->AllocTextureImageBuffer. That function
>> actually always frees the buffer and recreates a new one so it was
Nanley Chery writes:
> Although most of the patch is incorrect, the following change is still
> necessary isn't it?
> if (mt->compressed) {
>mip1_width = ALIGN(minify(mt->physical_width0, 1), mt->align_w) +
> - ALIGN(minify(mt->physical_width0, 2), bw);
> +
brw_miptree_layout_2d tries to ensure that mt->total_width is a
multiple of the compressed block size, presumably because it wouldn't
be possible to make an image that has a fraction of a block. However
it was doing this by aligning mt->total_width to align_w. Previously
align_w has been used as a
Hi,
If we are going to have to prod all of the code using this list
implementation to solve this problem anyway maybe it would make more
sense to switch to a kernel-style list instead. There is already an
implementation of this in src/util/list.h. I think this style of list
only accesses the point
Ben Widawsky writes:
> I think this is beginning to infringe upon the definition of align_w.
> The total width is a function of it's miptree properties and not the
> compressed block properties, right?
>
> In other words, if there is a case where align_w != bw, I think
> total_width should be ali
Since commit 104c8fc2c2aa5621261f8 the GLSL IR will be freed if NIR is
being used. This was causing it to segfault if INTEL_DEBUG=wm is set.
This patch just makes it avoid dumping the GLSL IR in that case.
---
src/mesa/drivers/dri/i965/brw_program.c | 11 +++
1 file changed, 7 insertions(+
For centroid interpolation we can just directly use the values set up
in the shader payload instead of querying the pixel interpolator. To
do this we need to modify brw_compute_barycentric_interp_modes to
detect when interpolateAtCentroid is called.
This fixes the interpolateAtCentroid tests on SK
Ben Widawsky writes:
> I am not the right person to judge the complexity tradeoff, but it
> seems like a worthwhile patch to me. I spent a few minutes thinking
> about how it could hurt performance and was unable to come up with
> anything.
Thanks. I was thinking more that the complexity means m
Hi,
If we wanted to avoid growing the size of exec_list to four pointers
instead of three, maybe we could store it in a union like below:
struct exec_list {
union {
struct {
struct exec_node head_sentinel;
struct exec_node *dummy_pointer_a;
};
struct {
Davin McCall writes:
> I actually had thought about this, but technically, you can only use
> unions for type aliasing if you perform all accesses (that are not to
> the 'active' member) through the union. All the list processing code
> that iterates through all the nodes including the tail senti
There was a comment saying that in SIMD16 mode the pixel interpolator
returns coords interleaved 8 channels at a time and that this requires
extra work to support. However, this interleaved format is exactly
what the PLN instruction requires so I don't think anything needs to
be done to support it
On Gen9+ there is a new bit in 3DSTATE_PS_EXTRA that must be set if
the shader sends a message to the pixel interpolator. This fixes the
interpolateAt* tests on SKL, apart from interpolateatsample-nonconst
but that is not implemented anywhere so it's not a regression.
---
src/mesa/drivers/dri/i965
There is a piece of code that is trying to match expressions of the
form (mul (floor (add (abs x) 0.5) (sign x))). However the check for
the add expression wasn't checking whether it had the expected
operation. It looks like this was just an oversight because it doesn't
match the pattern for the re
In this bit of code point_five can be NULL if the expression is not a
constant. This fixes it to match the pattern of the rest of the chunk
of code so that it checks for NULLs.
Cc: Matt Turner
Cc: "10.6"
---
src/glsl/opt_algebraic.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
For centroid interpolation we can just directly use the values set up
in the shader payload instead of querying the pixel interpolator. To
do this we need to modify brw_compute_barycentric_interp_modes to
detect when interpolateAtCentroid is called.
v2: Rebase on top of changes to set the pulls ba
When the edge flag element is enabled then the elements are slightly
reordered so that the edge flag is always the last one. This was
confusing the code to upload the 3DSTATE_VF_INSTANCING state because
that is uploaded with a separate loop which has an instruction for
each element. The indices use
Chris Forbes writes:
> Nitpicks aside, I don't think this is a great idea now that you've got
> the SKL PI working.
Can you explain why you don't think this is a good idea? Is it because
it is an optimisation for something that is not known to be a big use
case so carrying around the extra code
When gl_VertexID or gl_InstanceID is used a 3DSTATE_VF_SGVS
instruction is sent to create a sort of element to store the generated
values. The last instruction in this chunk of code looks like it was
trying to set the instancing state for the element using the
3DSTATE_VF_INSTANCING instruction. How
This series fixes these two related bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=84677
https://bugs.freedesktop.org/show_bug.cgi?id=91292
The first bug has had a fix for a while but until now I wasn't able to
figure out what to do on BDW. I had previously made a fix for the
second bug but a
When the edge flag element is enabled then the elements are slightly
reordered so that the edge flag is always the last one. This was
confusing the code to upload the 3DSTATE_VF_INSTANCING state because
that is uploaded with a separate loop which has an instruction for
each element. The indices use
The edge flag data on Gen6+ is passed through the fixed function hardware as
an extra attribute. According to the PRM it must be the last valid
VERTEX_ELEMENT structure. However if the vertex ID is also used then another
extra element is added to source the VID. This made it so the vertex ID is in
If a non-const sample number is given to interpolateAtSample it will
now generate an indirect send message with the sample ID similar to
how non-const sampler array indexing works. Previously non-const
values were ignored and instead it ended up using a constant 0 value.
Note that unlike sampler a
Ben Widawsky writes:
> The impetus for this patch comes from a seemingly benign statement within the
> spec (quoted within the patch). For me, this patch was at some point critical
> for getting stable piglit results (though this did not seem to be the case on
> a
> branch Chad was working on).
This patch doesn't look right. See this sentence in “Render Target Fast
Clear”:
“The pixel shader kernel requires no attributes, and delivers a value of
0x in all channels of the render target write message”
Presumably the fast_clear_color is trying to implement this restriction.
Regard
It would be nice if you could give some indication of where this list of
formats came from.
Unless we expect the list to change with future generations, maybe it
would be better to make it a static const table? It's a shame to grow
the context size unnecessarily.
Regards,
- Neil
Ben Widawsky wr
Looks good, it'll be great to get this landed. Patches 1-3 and 6-8 are:
Reviewed-by: Neil Roberts
I've sent comments separately for 4, 5 and 9. Hopefully I can try to
help with patch 10 once my SKL machine arrives.
Regards,
- Neil
Ben Widawsky writes:
> This patch series add
Ping, could you please push this patch? It's a pain to use the optimise
debug output without it. Thanks.
Reviewed-by: Neil Roberts
- Neil
Jason Ekstrand writes:
> This has the better name to use. Aparently, sh->Name is usually 0.
> ---
> src/glsl/nir/glsl_to_nir.cpp | 2 +-
Instead of just running a couple of the possible optimisations in one
single iteration, it now runs the whole loop again after lowering the
load payloads. According to shader-db this gives:
total instructions in shared programs: 6493365 -> 6493289 (-0.00%)
instructions in affected programs: 16
91f466fb8558106d2aaa
Either way though I don't think it would do any harm to have Kristian's
patch as well even if we did improve elimintate_find_live_channel so it
is:
Reviewed-by: Neil Roberts
- Neil
Kristian Høgsberg Kristensen writes:
> An immdiate is already uniform so just
Since 49374fab5d793 these macros no longer actually use the block
argument. I think this is worth doing to make the macros easier to use
because they already have really long names and a confusing set of
arguments.
---
src/mesa/drivers/dri/i965/brw_cfg.h | 4 ++--
src/mesa/dr
The opt_zero_samples instruction tries to find the corresponding
load_payload instruction for each sample instruction. However it was
previously only looking at the previous instruction. This patch makes
it search back within the block to whatever was the last instruction
to write to each individua
In bfdae9149e0 I disabled the opt_sampler_eot optimisation for TG4
message types because I found by experimentation that it doesn't work.
I wrote in the comment that I couldn't find any documentation for this
problem. However I've now found the documentation and it has
additional restrictions on fu
Ilia Mirkin writes:
>> - if (tex_inst->opcode == SHADER_OPCODE_TG4 ||
>> + if (tex_inst->opcode == SHADER_OPCODE_TXS ||
>> + tex_inst->opcode == SHADER_OPCODE_LOD ||
>> + tex_inst->opcode == SHADER_OPCODE_TG4 ||
>> tex_inst->opcode == SHADER_OPCODE_TG4_OFFSET)
>
> Do you a
es here:
https://github.com/bpeel/mesa/tree/wip/16x-msaa
Thanks.
- Neil
Neil Roberts writes:
> Previously there was a problem in i965 where if 16x MSAA is used then
> some of the sample positions are exactly on the 0 x or y axis. When
> the MSAA copy blit shader interpolates th
Ian Romanick writes:
>> To fix that this patch makes it use interpolateAtOffset in the blit
>> shader whenever 16x MSAA is used and the GL_ARB_gpu_shader5 extension
>> is available. This forces it to interpolate the texture coordinates at
>> the pixel center to avoid these problematic positions.
Previously this extension was only enabled when blitting between two
multisampled buffers. However I don't think it does any harm to just
enable it all the time. The ‘enable’ option is used instead of
‘require’ so that the shader will still compile if the extension isn't
available in the cases wher
Previously there was a problem in i965 where if 16x MSAA is used then
some of the sample positions are exactly on the 0 x or y axis. When
the MSAA copy blit shader interpolates the texture coordinates at
these sample positions it was possible that it would jump to a
neighboring texel due to roundin
Nanley Chery writes:
> + /* Throw an INVALID_OPERATION error if the target is
> + * TEXTURE_CUBE_MAP_ARRAY and the format is not ASTC.
> + */
> + if (target_can_be_compresed &&
> + ctx->Extensions.KHR_texture_compression_astc_ldr &&
> + layout != MESA_FORMA
It seems that if you have a surface format with less than 4 components
then the sampler still reports the fast color clear value for the
components that are missing. So for example if you clear a GL_RED
surface to 1,1,1,1 then the sampling instructions will return 1,1,1,1
instead of 1,0,0,1. Normal
Previously the GL spec required that whenever glBlitFramebuffer is
used with either buffer being multisampled, the internal formats must
match. However the GL 4.4 spec was later changed to remove this
restriction. In the section entitled “Changes in the released
Specification of July 22, 2013” it s
Neil Roberts writes:
> Normally this doesn't matter because fast color clears are only
> available on Gen7+ and for that hardware we also always set the
> texture swizzle to force the missing components to zero or one.
Looking at it a bit more I think this part is wrong and it do
Ben Widawsky writes:
> It seems reasonable to me, but since you touch the same code I touch
> in fast clears, and since I always screw up rebases, any chance I
> could persuade you to wait until I land fast clears?
Sure, I don't mind waiting. I did have a go at rebasing the patch on top
of your
ts.freedesktop.org/archives/mesa-dev/2015-November/099274.html
Regards,
- Neil
>
> v2: Just reject the two failing types.
>
> Cc: Neil Roberts Signed-off-by: Ben Widawsky
> ---
> src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 12 ++--
> src/mesa/drivers/dri/i96
It looks like the sampler hardware doesn't take into account the
surface format when sampling a cleared color after a fast clear has
been done. So for example if you clear a GL_RED surface to 1,1,1,1
then the sampling instructions will return 1,1,1,1 instead of 1,0,0,1.
This patch makes it override
Ben Widawsky writes:
> Here is one proposal to fix the issue. I noticed that only formats
> without alpha were failing. This sucks for RGBX formats (which
> technically aren't fast clearable based on the surface format). The
> hunk for moving the format should happen regardless of this patch.
If
Hi,
You don't seem to have included any of the suggestions I made in my
review. Was this deliberate? If not, the main points were:
• You don't need to call brw_fast_clear_init or use_rectlist in the
function because these are already called before entering it.
• I don't think it's worth creati
Ben Widawsky writes:
> Thanks a lot, I will squash it in - and sorry again about ignoring your
> feedback.
Ok, no worries. Feel free to add
Reviewed-by: Neil Roberts
if you squash the changes in.
Regards,
- Neil
___
mesa-dev mailing list
me
There are currently a bunch of formats that behave strangely when
sampling the cleared color from the MCS buffer on SKL. They seem to
mostly be formats that don't have an alpha component, although it's
not all of them, and we haven't yet found anything in the specs which
would explain this. For now
Ben Widawsky writes:
>> + case GL_LUMINANCE:
>> + case GL_LUMINANCE_ALPHA:
>> + override_color.ui[1] = override_color.ui[0];
>> + override_color.ui[2] = override_color.ui[0];
>> + break;
>
> The definition for GL_LUMINANCE afaict: "Each element is a single
> luminance value. Th
According to the SkyLake bspec the 3DSTATE_CONSTANT_* commands only take
effect on the next corresponding 3DSTATE_BINDING_TABLE_POINTER_* command. This
patch just makes it set the BRW_NEW_SURFACES state when uploading the push
constants to ensure the binding tables will be updated.
This fixes the
This limits the style changes to modes inherited from prog-mode. The
main reason to do this is to avoid setting fill-column for people
using Emacs to edit commit messages because 78 characters is too many
to make it wrap properly in git log. Note that makefile-mode also
inherits from prog-mode so t
This limits the style changes to modes inherited from prog-mode. The
main reason to do this is to avoid setting fill-column for people
using Emacs to edit commit messages because 78 characters is too many
to make it wrap properly in git log. Note that makefile-mode also
inherits from prog-mode so t
Hi Marius,
This patch does indeed make the Piglit test pass but it doesn't seem
like a complete fix. It looks like there are still a number of places
that are copying via floats that the test wouldn't catch. There are also
lots of places that are still using GLfloat to store the attribute
values a
I made a similar patch in my local tree because it will be necessary for
Skylake which doesn't support tiling for 1D textures. I made a little
test to time rendering a large (4096) 1D texture here:
https://github.com/bpeel/glthing/tree/time-1d-texture
It gives about an 11% increase in FPS with th
Looks good to me.
Reviewed-by: Neil Roberts
- Neil
Francisco Jerez writes:
> It doesn't really improve locality of texture fetches, quite the
> opposite it's a waste of memory bandwidth and space due to tile
> alignment.
>
> v2: Check mt->logical_height0 inste
Skylake+ doesn't support setting a depth buffer to a 1D surface but it
does allow pretending it's a 2D texture with a height of 1 instead.
This fixes the GL_DEPTH_COMPONENT_* tests of the copyteximage piglit
test (and also seems to avoid a subsequent GPU hang).
Bugzilla: https://bugs.freedesktop.
Skylake has changed 1D textures so that the mipmaps are stored more
efficiently and the qpitch is calculated differently. These two
patches combined fix the following Piglit tests:
clear-color-all-types 1d_array mipmapped
clear-color-all-types 1d_array single_level
fbo-generatemipmap-1d
texsubimag
On Gen9+ the 1D miptree is laid out with all of the mipmap levels in a
horizontal line.
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 71 --
1 file changed, 68 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b/src/mesa/drivers/
According to the bspec since Skylake the qpitch value in the surface
formats should be measured in pixels rather than rows for 1D textures.
---
src/mesa/drivers/dri/i965/gen8_surface_state.c | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/src/mesa/dr
Ben Widawsky writes:
> I promise to look at this again in more detail tomorrow when I am more
> awake, but meanwhile, I'd be very much in favor of just setting
> mt->qpith for all miptree layout types.
I'm not sure what you mean. Do you mean that we should just always set
mt->qpitch to the actua
Ian Romanick writes:
> There aren't any compressed formats that support 1D textures, so I
> don't think this can occur. Does the bspec say anything about
> compressed 1D textures?
Ah yes, you're right. I just copied it from brw_miptree_layout_2d
without really thinking it through. The SKL bspec
Here is a v2 of my patch series to fix 1D textures on Skylake. It's
now turned into just some general fixes and also helps with 3D
textures. It fixes 110 piglit tests but sadly seems to cause 3
regressions. It might not be worth landing until I can work out what
the regressions are so I guess I'm j
Sandybridge doesn't support y-tiling for surface formats with 16 or
more bpp. There was previously an override to explicitly allow this
for Gen7. However, this restriction is also removed in Gen8+ so we
should use y-tiling there too.
This is important to do for Skylake which doesn't support x-tili
The render surface state command for Skylake doesn't have the surface
array spacing bit so I don't think it's possible to select this
layout. This avoids a kernel panic when running the piglit test below:
ext_framebuffer_multisample-no-color 8 stencil single
However the test still fails so there
On Skylake it is possible to choose your own alignment values for
compressed textures but they are expressed as a multiple of the block
size. The minimum alignment value we can use is 4 so we effectively
have to align to 4 times the block size. This patch makes it initially
set mt->align_[wh] to th
On Gen9+ the 3D textures use the same mipmap layout as 2D array
textures.
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b/src/mesa/drivers/dri/i965/brw_tex_layout.c
index 0e2
On Gen9+ the 1D miptree is laid out with all of the mipmap levels in a
horizontal line.
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 62 +-
1 file changed, 60 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b/src/mesa/drivers/
On Skylake the qpitch value is uploaded as part of the surface state
so we don't need to add the extra rows that are done for other
generations. However for 3D textures it needs to be aligned to the
tile height. Unlike previous generations the qpitch is measured as a
multiple of the block size for
On Skylake the qpitch value is uploaded as part of the surface state
so we don't need to add the extra rows that are done for other
generations. However for 3D textures it needs to be aligned to the
tile height and for depth/stencil textures it needs to be a multiple
of 8. Unlike previous generatio
Anuj Phogat writes:
> using a flag passed in as function parameter. This will enable
> _mesa_meta_pbo_GetTexSubImage to be used for reading in to
> non-pbo buffers.
>
> This will be useful to support reading from YF/YS tiled surfaces
> in Skylake.
>
> Signed-off-by: Anuj Phogat
> ---
> src/mesa
an extra space of indentation in the old version
which made it clearer that it is inside the brackets above. I think the
space should be added back here.
The patch is an improvement so I think it's worth landing but I wonder
if now that's in a separate function it might be worth tidying it up a
b
It seems like it would be better to fold this into patch 4 because it
is fixing a problem that is effectively introduced by that patch,
isn't it?
Regards,
- Neil
pgphPhjb7Gl0I.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.free
All of these patches except 4, 10 and 12 look good to me and are:
Reviewed-by: Neil Roberts
However, I'm still relatively new to this so maybe my review should be
taken with a pinch of salt.
I've replied with comments for the three patches mentioned.
Regards,
- Neil
pgpW3_Z
Ben Widawsky writes:
>> + if (mt->target == GL_TEXTURE_3D)
>> + depth = minify(depth, 1);
>> }
>> }
>
> assert(brw->gen >= 9)? (up to you, I'm very assert happy)
Yes, that seems like a good idea.
>>
>> @@ -263,7 +266,7 @@ brw_miptree_layout_texture_array(struct brw_context *
Ben Widawsky writes:
> Okay, I'm guilty of a bikeshed here, but doesn't this look cleaner if you just
> do two for loops? One for depth, and one for levels.
>
> something like...
> const unsigned depth = mt->physical_depth0;
> for (i = 0; i < depth; i++) {
> width = mt->physical_width0;
>
Ben Widawsky writes:
>> + if (layout_1d) {
>> + physical_qpitch = mt->align_h;
>> + /* When using the horizontal layout the qpitch is measured in pixels
>> */
>
> I think the docs words are a bit clearer:
> "Surface QPitch specifies the distance in pixels between array
> slices."
Ok
A layered PBO image is now interpreted as a single tall 2D image so
the z argument in _mesa_meta_bind_fbo_image is ignored. Therefore this
was just redundantly rebinding the same image repeatedly.
---
src/mesa/drivers/common/meta_tex_subimage.c | 4
1 file changed, 4 deletions(-)
diff --git
Sorry for the late review.
Can you explain what this patch does? The previous code was doing a blit
like this:
_mesa_meta_BlitFramebuffer(ctx, ctx->ReadBuffer, ctx->DrawBuffer,
0, z * height, width, (z + 1) * height,
xoffset,
Now that a layered source PBO is interpreted as a single tall 2D image
it's quite easy to accept the image height packing option by just
creating an image that is tall enough to include the image padding.
This is tested by the texsubimage Piglit test with the array and pbo
arguments. Previously th
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.
+ *
+ *
+ * Test that GL_PACK_IMAGE_HEIGHT and GL_UNPA
Ian Romanick writes:
> IMAGE_HEIGHT is definitely used for glGetTexImage because that and
> IMAGE_WIDTH allow you to get a subimage (before ARB_get_texture_sub_image).
>
> I guess on glTexImage2D those could let you initialize a subregion of a
> larger texture... kind of like doing glTexImage2D(.
According to the bspec for some reason the format of the maximum
number of threads field has changed from U8-2 to U8-1 for the PS.
I've run this through Piglit and it doesn't cause any regressions.
---
src/mesa/drivers/dri/i965/gen8_ps_state.c | 7 ++-
1 file changed, 6 insertions(+), 1 delet
The vertical alignment is ignored in the surface state for 1D array
textures so we can tightly pack them.
I've run this through Piglit and it doesn't cause any regressions.
(This should probably be squashed into the patch entitled “i965/skl:
Fix the qpitch value”)
---
src/mesa/drivers/dri/i965/b
Ben Widawsky writes:
> I guess I'd appreciate a comment about how the total_width is
> guaranteed to be a multiple of 64, and therefore is a multiple of all
> possible H_ALIGNS. This is required to meet the qpitch restraint in
> the surface format, "This field must be set to an integer multiple o
7;s really easy to get it wrong.
I think the patch could do with a small commit message mentioning that
the scissor and SRGB states were broken.
Either way,
Reviewed-by: Neil Roberts
Regards,
- Neil
Jason Ekstrand writes:
> Cc: 10.5
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?
Jason Ekstrand writes:
> On Mon, Mar 2, 2015 at 11:33 AM, Ilia Mirkin wrote:
>
>> On Mon, Mar 2, 2015 at 2:32 PM, Jason Ekstrand
>> wrote:
>> >
>> >
>> > On Mon, Mar 2, 2015 at 11:18 AM, Ilia Mirkin
>> wrote:
>> >>
>> >> Hmmm... I was just looking at this code in connection to attepmting to
>>
Stepping C0 of Skylake fails when using SIMD16 with 3-source
instructions (such as MAD). This patch just makes it disable SIMD16 in
that case.
This implements WaDisableSIMD16On3SrcInstr and fixes ~190 Piglit
tests.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 21 +
src/mesa/driv
brwContextInit now queries the GPU revision number via a new parameter
for DRM_I915_GETPARAM. This new parameter requires a kernel patch and
a patch to libdrm. If the kernel doesn't support it then it will
continue but set the revision number to -1. The intention is to use
this to implement workaro
Ilia Mirkin writes:
> On Wed, Mar 4, 2015 at 9:33 AM, Neil Roberts wrote:
>> Stepping C0 of Skylake fails when using SIMD16 with 3-source
>> instructions (such as MAD). This patch just makes it disable SIMD16 in
>> that case.
>>
>> This implements WaDisabl
Steppings C0 and D0 of Skylake fail when using SIMD16 with 3-source
instructions (such as MAD). This patch just makes it disable SIMD16 in
those cases.
This implements WaDisableSIMD16On3SrcInstr and fixes ~190 Piglit
tests.
v2: Also apply on stepping D0
---
Damien Lespiau pointed out that the wo
The yoffset needs to be interpreted as a slice offset for 1D array
textures. This patch implements that by moving the yoffset into
zoffset similar to how it moves the height into depth.
---
src/mesa/drivers/common/meta_tex_subimage.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/
Now that a layered source PBO is interpreted as a single tall 2D image
it's quite easy to accept the image height packing option by just
creating an image that is tall enough to include the image padding.
I'm not sure whether the image height property should affect 1D_ARRAY
textures. My intuition
This reverts commit 546aba143d13ba3f993ead4cc30b2404abfc0202.
I think the changes to the calls to glBlitFramebuffer from this patch
are no different to what it was doing previously because it used to
set height to 1 before doing the blits. However it was introducing
some problems with the blit for
Yes, I like this approach much better. I ran it through Piglit and I can
confirm it fixes the same tests as my patch.
Reviewed-by: Neil Roberts
There's no need to reset the author to me. Thanks for looking at this.
Regards,
- Neil
Kenneth Graunke writes:
> Several steppings of Skyl
1 - 100 of 506 matches
Mail list logo
