code level
that only one of the two is possible without texture invalidates.
-Kevin
-Original Message-
From: Topi Pohjolainen [mailto:topi.pohjolai...@gmail.com]
Sent: Monday, December 4, 2017 12:49 PM
To: mesa-dev@lists.freedesktop.org
Cc: Rogovin, Kevin
Subject: [PATCH] RFC: Worka
Hi,
>> Here are my comments of the patch posted:
>>
>> 1. it is essentially replication and moving around of the code of the
>> patch series posted earlier but missing various
>> important bits: preventing the sampler from using the auxiliary buffer
>> (this requires to modify surface
> If you take a look at brw_update_texture_surface(), just in the end before
> brw_emit_surface_state() the logic explictly consults for
> intel_miptree_texture_aux_usage().
> This in turn tells if the auxiliary buffer is resolved and it doesn't need to
> be programmed.
The full stack trace is
> Are you saying that this bug extends over hardware context?
Different HW contexts imply different execbuffer2 ioctl's. The kernel inserts a
full blown flush of everything after (or before, I cannot remember) each
execbuffer2 call. This way there is context isolation in HW buggineness.
-Kevin
Hi,
>This isn't true. 100% of the intel_mipmap_tree -> blorp_surf translations are
>handled by that function.
> It's a perfectly reasonable place to handle these things. It could also be
> handled in genX(blorp_exec) if that makes someone more comfortable.
This is where I placed the ASTC en
>I'd have to think about it harder but even those are not likely to actually
>get ASTC decode. Maybe for some sort of decompression thing but if you're
>doing
> GetCompressedTexImage, it'll probably turn into a blorp_copy which will use
> R32G32B32A32_UINT.
I am thinking for the case where a
readability patch, I think it should land to aid
in readability of the code.
-Kevin
-Original Message-
From: Rogovin, Kevin
Sent: Tuesday, December 12, 2017 12:05 PM
To: mesa-dev@lists.freedesktop.org
Cc: Rogovin, Kevin
Subject: [PATCH 1/2] i965: correctly program MEDIA_VFE_STATE for compute
> These patches fix GPU hangs I'm seeing also with the *GL* version of
> CarChase on KBL GT3e, when using Ubuntu 16.04 kernel.
> NOTE: those hangs don't happen when doing tests with latest drm-tip
> kernel. Besides the older Ubuntu kernel, I'm seeing hangs also with the
> 4.13 drm-tip kernel,
Ahh futz this was the wrong one!! it should just be
subslices += 4 * brw->screen->devinfo.num_slices;
Sighs (too many terminals open with too many branches :P )
I need to post a v2; I will post it shortly.
-Kevin
-Original Message-
From: Rogovin, Kevin
Sent: Tuesday, Decem
t reviewed and land in Mesa so that
hunting for a certain classes of Heisenberg bugs can be less Heisenberg like.
Best Regards,
-Kevin
-Original Message-
From: Kenneth Graunke [mailto:kenn...@whitecape.org]
Sent: Tuesday, December 12, 2017 9:09 PM
To: mesa-dev@lists.freedesktop.org
C
Hi,
Thankyou for reading the code and giving advice to improve upon it. Below are
some thoughts:
> I can't help but think that this could be a bit simpler and involve throwing
> fewer pointers around.
I was thinking this too; the easiest way to do this is to just have the same
noise for all
Hi,
> I think you want to do this at the end of submit_batch instead and add a
> brw_bo_wait_rendering on the batch.
> Otherwise, your bounds checking is racing with the GPU.
I remember being told that pread has the kernel do the required waiting,
however I am not 100% sure of this (which is
Hi,
Just got confirmation that kernel does the syncing required to make sure that
pread values are realiable.
-Kevin
-Original Message-
From: Rogovin, Kevin
Sent: Wednesday, December 13, 2017 8:19 AM
To: 'Jason Ekstrand'
Cc: mesa-dev@lists.freedesktop.org; Lahtinen, Joona
Hi,
> Actually that's not strictly true. Since you only do a pread here, it will
> only synchronize against the last declared write to the bo.
> There's no guaranteed sync with the last batch for a set of read-only bo.
> Similarly, because of no domain tracking, it won't also ensure that the bo i
up to padding size), I think pread would be fine then.
Thoughts?
-Kevin
P.S. I am already writing it to do mapping and such, but it is more code sadly.
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Wednesday, December 13, 2017 1:23 PM
To: Rogovin, Kevin ; mes
Hi,
> Yes. It's just the accidental writes into the read-only bo that you may miss.
> Your call, and I have no
> objections if such limitations are described in the comments.
I'll add the comment; since there then less code to read (indeed using
brw_bo_map will not work because
it does not map
: Friday, December 15, 2017 8:34 PM
To: Rogovin, Kevin
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH v2 0/5] i965: ASTC5x5 workaround
On Thu, Dec 14, 2017 at 07:39:46PM +0200, kevin.rogo...@intel.com wrote:
> From: Kevin Rogovin
>
> This patch series implements a needed w
. When the value is zero, it means the GPU will not prefetch the
binding table entries.
-Kevin
-Original Message-
From: Landwerlin, Lionel G
Sent: Monday, September 25, 2017 3:10 PM
To: Rogovin, Kevin ; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 04/22] i965: assign
Sent: Tuesday, September 26, 2017 2:53 AM
To: Landwerlin, Lionel G ; Rogovin, Kevin
; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 05/22] i965: correctly assign SamplerCount of
INTERFACE_DESCRIPTOR_DATA
On 2017-09-25 05:46:32, Lionel Landwerlin wrote:
> I'm genuinely surpri
ould leave behind a file).
Let me know, what is best, and I will do it.
-Kevin
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Tuesday, September 26, 2017 11:20 PM
To: Rogovin, Kevin ; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 00/2
is to send the api-trace call id's to the kernel on
execbuffer2, then this does not matter.
-Kevin
-Original Message-
From: Rogovin, Kevin
Sent: Wednesday, September 27, 2017 9:53 AM
To: 'Chris Wilson' ; mesa-dev@lists.freedesktop.org
Subject: RE: [Mesa-dev] [P
nel G
Sent: Wednesday, September 27, 2017 12:35 PM
To: Rogovin, Kevin ; Chris Wilson
; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 00/22] RFC: Batchbuffer Logger for Intel GPU
A few months ago I implemented debug messages in the command stream by stuffing
the unused bits of MI
make such a dedicated tool quite quickly, or add that
functionality to the logger.
-Kevin
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Wednesday, September 27, 2017 1:21 PM
To: Rogovin, Kevin ; mesa-dev@lists.freedesktop.org
Subject: RE: [Mesa-dev] [PATCH
>My worry is that batch->bo is not constant for the construction of a single
>execbuf2.
> If intel_batchbuffer.c runs out of room inside the batch->bo, it will
> allocate a new one and continue building it.
That will be ok, but if the (fd, GEM BO handle) changes, there is a serious
issue.
> I
ented fixes for the issue that Chris pointed out
on batchbuffer migration and a pair of issues I realized on the script at patch
17).
Best Regards,
-Kevin
-Original Message-
From: Rogovin, Kevin
Sent: Wednesday, September 27, 2017 2:38 PM
To: Chris Wilson ; mesa-dev@lists.freedeskto
Hi,
I followed the convention that was already present. The code from
ARB/NV_fragment_shader_interlock had an intrinsic for begin critical section
and an intrinsic for end critical section. I figured that since this extension
has a completely different thinking (i.e. a memory barrier instead of
Hi,
On the questions of tests: If people want, I can adapt the test in piglit for
ARB_fragment_shader_interlock to this INTEL one. In general, I have an
app/library that uses the extension and testing of that does definitely work on
i965 (which should be utterly unsurprising since the produced
they should be 3 different
intrinsics with the thinking that if the Nouveau driver adds support for the
ARB/NV extension it will do the IR analysis to do what is needed for the
critical-section style extension.
-Kevin
From: Rogovin, Kevin
Sent: Tuesday, August 28, 2018 7:05 PM
To: mesa-dev
Hi,
Sighs; I missed that warning on the build since there is so much build output.
I can issue a small patch to handle the missing enum.
-Kevin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa
Hi all,
Patch addressing the missing enum warning is here:
https://lists.freedesktop.org/archives/mesa-dev/2018-August/203796.html . Also,
see my reply to Francisco why I think it is better to have a new intrinsic
function for that.
Best Regards,
-Kevin
Hi,
> Having the same underlying compiler intrinsic and having the same behavior
> are not the same thing. The INTEL extension allows strictly more
> functionality than the ARB extension so it needs even more testing. In
> particular, it allows you to do the barrier in non-uniform control-flow
>
Hi,
> Is that tested?
I have tested it in a simple shader test I made (i.e. not in a dedicated test
suite such as dEQP, piglit or something else). The created assembly is
identical. The specific example is a shader where I replace calls of
beginFragmentShaderOrderingINTEL() with beginInvocatio
l to sort out and bow out of the
discussion at this point as the series seems to have brought additional issues
up that are out-of-scope for what I had in mind with the series (namely
something small-simple to expose the extension and not enforcing the limitation
of the ARB extension).
-Kevin
-
Originally, I had the entire astc and aux checking in a dedicated function;
would that be more preferable?
-Kevin
From: Jason Ekstrand [mailto:ja...@jlekstrand.net]
Sent: Tuesday, March 6, 2018 6:02 PM
To: Rogovin, Kevin
Cc: ML mesa-dev
Subject: Re: [Mesa-dev] [PATCH v3 3/7] i965: set ASTC5x5
passed down along
the function calls somehow …
-Kevin
From: Jason Ekstrand [mailto:ja...@jlekstrand.net]
Sent: Tuesday, March 6, 2018 6:07 PM
To: Rogovin, Kevin
Cc: ML mesa-dev
Subject: Re: [Mesa-dev] [PATCH v3 7/7] i965: ASTC5x5 workaround logic for blorp
On Tue, Feb 27, 2018 at 1:30 AM
.
-Kevin
From: Jason Ekstrand [mailto:ja...@jlekstrand.net]
Sent: Tuesday, March 6, 2018 6:00 PM
To: Rogovin, Kevin
Cc: ML mesa-dev
Subject: Re: [Mesa-dev] [PATCH v3 2/7] i965: restore diable_aux argument to
intel_miptree_prepare_texture()
We took it out with good reason... I'd rather
posted is
better; if that is not the case, then a nasty, hard to track bug will then lurk.
-Kevin
-Original Message-
From: Palli, Tapani
Sent: Friday, March 16, 2018 11:32 AM
To: mesa-dev@lists.freedesktop.org
Cc: ja...@jlekstrand.net; Rogovin, Kevin ; Palli,
Tapani
Subject: [PATCH v2
padding. This is following the
review comments from Chris Wilson.
-Kevin
From: Jason Ekstrand [mailto:ja...@jlekstrand.net]
Sent: Friday, January 26, 2018 12:13 PM
To: Rogovin, Kevin
Cc: ML mesa-dev
Subject: Re: [Mesa-dev] [PATCH v3 2/3] i965: add noise padding to buffer object
and function to
Sure, I can change the bit flag name to DEBUG_CHECK_OOB;
From: Jason Ekstrand [mailto:ja...@jlekstrand.net]
Sent: Friday, January 26, 2018 12:11 PM
To: Rogovin, Kevin
Cc: ML mesa-dev
Subject: Re: [Mesa-dev] [PATCH v3 1/3] intel/common:add debug flag for adding
and checking padding on BO'
, 2018 6:41 PM
To: Rogovin, Kevin
Subject: RE: [PATCH v3 3/3] i965: if DEBUG_OUT_OF_BOUND_CHK is up, check that
noise padding for each bo used in batchbuffer is correct
Nope. That one looked fine as-is.
On January 28, 2018 23:13:40 "Rogovin, Kevin" wrote:
> Any comments/revie
bruary 7, 2018 2:35 AM
To: mesa-dev@lists.freedesktop.org; Rogovin, Kevin
Subject: [PATCH RFC] intel/tools: new intel_sanitize_gpu tool
From: Kevin Rogovin
Adds a new debug tool to pad each GEM BO allocated with (weak) pseudo-random
noise values which are then checked after each batchbuffer dispatc
or if the application is using OpenGL and OpenCL (or
libva) ).
2. I would also handle the destroy GEM ioctl to remove its entry from the map.
-Kevin
-Original Message-
From: Phillips, Scott D
Sent: Wednesday, February 7, 2018 2:35 AM
To: mesa-dev@lists.freedesktop.org; Rogovin,
.
-Kevin
From: Jason Ekstrand [mailto:ja...@jlekstrand.net]
Sent: Thursday, February 8, 2018 2:47 AM
To: Rogovin, Kevin
Cc: ML mesa-dev
Subject: Re: [Mesa-dev] [PATCH v2 0/5] i965: ASTC5x5 workaround
Random thought:
Nanley and I were talking about this just now and I was complaining about how
HI,
Review comments below.
-Original Message-
From: Phillips, Scott D
Sent: Thursday, February 8, 2018 2:19 AM
To: mesa-dev@lists.freedesktop.org; Rogovin, Kevin
Subject: [PATCH v2] intel/tools: new intel_sanitize_gpu tool
From: Kevin Rogovin
Adds a new debug tool to pad each GEM
ly in brw_draw.c for resolving
inputs).
-Kevin
-Original Message-
From: Palli, Tapani
Sent: Monday, February 12, 2018 10:14 AM
To: Rogovin, Kevin ; Jason Ekstrand
Cc: ML mesa-dev
Subject: Re: [Mesa-dev] [PATCH v2 0/5] i965: ASTC5x5 workaround
On 02/12/2018 09:44 AM, Tapani Pälli wrote:
Reviewed by: kevin.rogovin [at] intel.com
-Original Message-
From: Phillips, Scott D
Sent: Friday, February 9, 2018 3:11 AM
To: mesa-dev@lists.freedesktop.org; Rogovin, Kevin
Subject: [PATCH v3] intel/tools: new intel_sanitize_gpu tool
From: Kevin Rogovin
Adds a new debug tool to pad
ssage-
From: Palli, Tapani
Sent: Wednesday, February 14, 2018 9:58 AM
To: Rogovin, Kevin ; Jason Ekstrand
Cc: ML mesa-dev
Subject: Re: [Mesa-dev] [PATCH v2 0/5] i965: ASTC5x5 workaround
On 14.02.2018 09:54, Tapani Pälli wrote:
>
>
> On 14.02.2018 09:38, Rogovin, Kevi
, August 24, 2017 8:10 PM
To: Rogovin, Kevin
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] i965: add 2xMSAA and 16xMSAA to DRI configs for
Gen9.
On 17-08-24 14:16:39, kevin.rogo...@intel.com wrote:
>From: Kevin Rogovin
>
>Special thanks to Eero Tamminen for reporting r
101 - 148 of 148 matches
Mail list logo
