I've definitely used the pipe_reference_described debugging code to
track down some issues when working on iris.
--Ken
On Monday, December 27, 2021 4:18:16 PM PST Marek Olšák wrote:
> I remember that it wasn't unusual on Windows to define malloc, calloc,
> strdup, and free macros to redirect
On Tuesday, December 7, 2021 12:26:29 PM PST Emma Anholt wrote:
> On Mon, Dec 6, 2021 at 3:50 PM Dylan Baker wrote:
> >
> > Classic is gone, and the cleanups have begun, obviously. There is
> > another cleanup that I had in mind, which is moving src/mesa into
> > src/gallium/frontends/mesa. This
Auld
> Cc: Joonas Lahtinen
> Cc: Thomas Hellström
> Cc: Daniele Ceraolo Spurio
> Cc: Lionel Landwerlin
> Cc: Jon Bloomfield
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
> Cc: Jason Ekstrand
> Cc: Dave Airlie
> Cc: dri-de...@lists.freedesktop
e/create-ext-placement-each
> Testcase: igt/gem_create/create-ext-placement-all
> Signed-off-by: Matthew Auld
> Signed-off-by: CQ Tang
> Cc: Joonas Lahtinen
> Cc: Daniele Ceraolo Spurio
> Cc: Lionel Landwerlin
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc:
On Wednesday, April 28, 2021 9:56:25 AM PDT Jason Ekstrand wrote:
> On Wed, Apr 28, 2021 at 11:41 AM Matthew Auld wrote:
[snip]
> > Slightly orthogonal: what does Mesa do here for snooped vs LLC
> > platforms? Does it make such a distinction? Just curious.
>
> In Vulkan on non-LLC platforms, we
On Monday, April 26, 2021 2:38:53 AM PDT Matthew Auld wrote:
> +Existing uAPI issues
> +
> +Some potential issues we still need to resolve.
> +
> +I915 MMAP
> +-
> +In i915 there are multiple ways to MMAP GEM object, including mapping the
> same
> +object using
On Thursday, March 25, 2021 2:04:45 PM PDT Ian Romanick wrote:
> On 3/25/21 10:49 AM, Jason Ekstrand wrote:
[snip]
> > I'm not sure we want to totally declare those drivers dead. People can
> > still do feature or enhancement development of they want to, it just
> > happens in a different branch.
On Thursday, March 25, 2021 10:15:51 AM PDT Rob Clark wrote:
> Other than the minor detail that we don't have pci-id's to
> differentiate between adreno generations, I might suggest a2xx users
> to use -lts
>
> BR,
> -R
Could it be set up such that freedreno in mainline fails to load on
a2xx
+1 to recommending the use of US English spelling in Mesa docs & code.
I certainly would not want to impose any heavy burdens on contributors
who are accustomed to UK/AU spelling. I don't think we should block any
patches because of UK/US/AU spelling, and people should feel free to
not think
On Tuesday, March 23, 2021 6:28:23 AM PDT Jason Ekstrand wrote:
> On March 23, 2021 01:46:54 Kenneth Graunke wrote:
[snip]
> > One extra thought: can we also fork off anv Gen7.x support at the same
> > time? If distros are already going to be building i965 for Gen7.x from
On Monday, March 22, 2021 3:15:30 PM PDT Dylan Baker wrote:
> Hi list,
>
> We've talked about it a number of times, but I think it's time time to
> discuss splitting the classic drivers off of the main development branch
> again, although this time I have a concrete plan for how this would
>
Seems reasonable to me...in the old Subversion days, we called it
'trunk'...then 'master' with Git...but calling the main development
branch 'main' is arguably the simplest and most descriptive term.
One thing we'll have to coordinate: getting Gitlab CI / Marge and the
Intel Mesa CI to switch
On Friday, July 31, 2020 7:14:49 AM PDT Mike Blumenkrantz wrote:
> Hi,
>
> I'd like to request marge access for the piglit and mesa gitlab projects.
> I've been contributing a number of patches here (primarily to
> zink/gallium), and this would be useful in my continued work.
>
>
> Regards,
>
Please note that Mesa 20.0 now defaults to the 'iris' driver for Intel
Gen8+ GPUs, and so you may want to set the -Dprefer-iris build option.
See this email for more details:
https://lists.freedesktop.org/archives/mesa-maintainers/2020-January/000150.html
--Ken
On Wednesday, February 19, 2020
Hello,
As most of you know, we've been developing a new 3D driver called 'iris'
for recent Intel hardware (Gen8+), based on the Gallium driver framework
used by the rest of the Mesa community. After two years of development,
we think that it's ready for production, and recommend it as the
On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote:
> Hi,
>
> Here are 2 proposals to simplify and better optimize the GL->Gallium
> translation.
>
> 1) Move classic drivers to a fork of Mesa, and remove them from master.
> Classic drivers won't share any code with master. glvnd will
Yeah...I thought the drawpixels lowering set up samplers directly with
explicit bindings. There should be no need to call it twice.
We can't handle setting textures_used in nir_shader_gather_info because
that is called both before and after lowering, and some of the
information needed is no
Hi all,
iris is now officially a conformant OpenGL 4.6 implementation!
https://www.khronos.org/conformance/adopters/conformant-products/opengl#submission_253
This is on Gen9. I've also submitted for Gen8, but that's still under
review; Gen11 is 99% of the way there but I'm hunting down one
Hi all,
As a lot of you have probably noticed, Bugzilla seems to be getting a
lot of spam these days - several of us have been disabling a bunch of
accounts per day, sweeping new reports under the rug, hiding comments,
etc. This bug spam causes emails to be sent (more spam!) and then us
to have
This patch is also:
Reviewed-by: Kenneth Graunke
though it would probably be best if Jason or Lionel reviewed it as well.
On Friday, August 9, 2019 5:20:39 PM PDT Francisco Jerez wrote:
> See "i965/gen9: Optimize slice and subslice load balancing behavior."
> for the ra
PENGL_CORE_PROFILE_BIT_KHR)
> api = __DRI_API_OPENGL_CORE;
> + else if (dri2_ctx->base.ClientMajorVersion == 3 &&
> + dri2_ctx->base.ClientMinorVersion == 1)
> + api = __DRI_API_OPENGL_CORE;
>else
> api = __DRI_API_OPENGL;
>
On Thursday, July 4, 2019 10:42:49 PM PDT Boris Brezillon wrote:
> On Thu, 04 Jul 2019 20:49:32 -0700
> Kenneth Graunke wrote:
>
> > On Thursday, July 4, 2019 5:23:44 AM PDT Boris Brezillon wrote:
> > > Hello,
> > >
> > > Alyssa recently pr
On Thursday, July 4, 2019 5:23:44 AM PDT Boris Brezillon wrote:
> Hello,
>
> Alyssa recently proposed that I push my own panfrost-related
> submissions once they received proper review and are considered
> ready to merged (meaning that received enough A-b/R-b tags).
>
> In order to do that, I'd
c_bo_from_cache
> points to and may zero the list pointers out.
>
> You may know best how to fix that.
>
> best and thanks
> Mathias
Ouch. Thanks for letting me know. Fixed by:
commit 53878f7a8989879b0f3ca37df9fd1fb37f2525ca
Author: Kenneth Graunke
Date: Wed May 29 23:20:31 2019 -
include "cso_cache/cso_cache.h"
>
> #include "st_context.h"
> #include "st_debug.h"
> #include "st_program.h"
>
>
>
> -#ifdef DEBUG
> int ST_DEBUG = 0;
Yes, please!
Patch 2 is:
Reviewed-by: Kenneth Graunke
signature.asc
Desc
with Vulkan CTS.
>
> CC: Kenneth Graunke
> CC: Jason Ekstrand
> CC: Anuj Phogat
> CC: Clayton Craft
> Signed-off-by: Topi Pohjolainen
Thanks Topi!
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
now that it's a PIPE_CAP. If
some driver wants a different value, they can override it.
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
* the conversion from floating-point to fixed-point coordinates.
> +*/
> PIPE_CONSERVATIVE_RASTER_PRE_SNAP,
> };
Thanks Marek, this makes a lot of sense and is helpful when trying to
remember what all of these options mean. :)
Reviewed-by: Kenneth Graunke
signat
On Monday, April 22, 2019 3:21:22 PM PDT Eric Anholt wrote:
> Jason Ekstrand writes:
>
> > All,
> >
> > I've seen discussions come up several times lately about whether you should
> > use MAYBE_UNUSED or UNUSED in what scenario and why do we have two of them
> > anyway. That got me thinking a
> if (drawable) {
>drawable->flushing = FALSE;
> }
It seems like this will let us submit one more batch before throttling,
which is a little like increasing the throttle value from 2 to 3...but
not exactly. I'm not sure I have an opinion on which is better...
The
On Wednesday, April 17, 2019 1:31:28 PM PDT Nanley Chery wrote:
> On Wed, Apr 17, 2019 at 11:34:15AM -0700, Rafael Antognolli wrote:
> > On Wed, Apr 17, 2019 at 09:04:09AM -0700, Kenneth Graunke wrote:
> > > On Wednesday, April 17, 2019 7:16:28 AM PDT Topi Pohjolainen wrote:
&g
On Wednesday, April 17, 2019 7:16:28 AM PDT Topi Pohjolainen wrote:
> From: Rafael Antognolli
>
> Fixes MCS fast clear gpu hangs with Vulkan CTS on ICL in CI.
>
> CC: Anuj Phogat
> CC: Kenneth Graunke
> Tested-by: Topi Pohjolainen
> Signed-off-by: Rafael Antognolli
On Tuesday, March 26, 2019 12:16:20 AM PDT Chris Wilson wrote:
> Quoting Kenneth Graunke (2019-03-26 05:52:10)
> > On Monday, March 25, 2019 3:58:59 AM PDT Chris Wilson wrote:
> > > iris currently uses two distinct GEM contexts to have distinct logical
> > > HW contexts
be
> constructed as the user desires.
>
> Cc: Joonas Lahtinen
> Cc: Kenneth Graunke
> ---
> src/gallium/drivers/iris/iris_batch.c | 16 ++-
> src/gallium/drivers/iris/iris_batch.h | 5 +--
> src/gallium/drivers/iris/iris_context.c | 56 -
> 3
;csmt_active = true;
> +else if (strstr(pScreen->get_name(pScreen), "Intel") != NULL)
> +This->csmt_active = true;
>
> /* We rely on u_upload_mgr using persistent coherent buffers (which don't
> * require flush to work in multi
On Wednesday, March 20, 2019 6:37:07 AM PDT Ilia Mirkin wrote:
> On Wed, Mar 6, 2019 at 3:32 AM Kenneth Graunke wrote:
> > There are no nouveau changes in this patch, but that's only because none
> > appeared to be necessary. Most drivers performed some kind of flush on
> &g
On Wednesday, March 13, 2019 4:25:24 PM PDT Jason Ekstrand wrote:
> We don't set it on HSW and earlier in i965 and disabling it appears to
> make derivatives somewhat more reliable.
>
> Cc: Kenneth Graunke
> ---
> src/intel/vulkan/genX_pipeline.c | 2 +-
> 1 file chang
_resource_create(pscreen, );
> if (!trans->ss) {
>free(trans);
>return NULL;
>
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
f no change can occur */
> +dsa.depth.writemask = !!rs[D3DRS_ZWRITEENABLE] &&
> +dsa.depth.func != PIPE_FUNC_EQUAL &&
> +dsa.depth.func != PIPE_FUNC_NEVER;
> }
>
> if (rs[D3DRS_STENCILENABLE]) {
>
I don't think we ac
Forgot Marek is on vacation. Nicolai, do you have an opinion?
It looks like you added the original comments that it isn't
necessary to handle these cases, too...
--Ken
On Thursday, March 7, 2019 3:48:04 PM PST Kenneth Graunke wrote:
> Hey Ilia, Marek,
>
> Do you have an opin
Hey Ilia, Marek,
Do you have an opinion about this? I've got a R-b from Eric Anholt
and what sounds like an Ack from Roland, but I wanted to make sure
everyone was OK with this before landing it.
--Ken
On Wednesday, March 6, 2019 12:32:23 AM PST Kenneth Graunke wrote:
> The glMemoryBarr
The glMemoryBarrier() function makes shader memory stores ordered with
respect to things specified by the given bits. Until now, st/mesa has
ignored GL_TEXTURE_UPDATE_BARRIER_BIT and GL_BUFFER_UPDATE_BARRIER_BIT,
saying that drivers should implicitly perform the needed flushing.
This seems like
On Tuesday, March 5, 2019 10:20:10 PM PST Dave Airlie wrote:
> On Wed, 6 Mar 2019 at 14:01, Brian Paul wrote:
> > I guess I don't fully understand a few things about the new meson build.
> >
> > 1. I'm trying to build the gallium VMware driver with this:
> >
> > export BUILD_DIR=build-meson-dri
>
On Friday, March 1, 2019 1:30:48 PM PST Dylan Baker wrote:
> Quoting Jordan Justen (2019-03-01 12:22:18)
> > I guess piglit makes very light usage of bugzilla. Would it be simpler
> > to just use gitlab issues in the piglit gitlab project?
> >
> > -Jordan
>
> I think we should, anecdotally it
,PIPE_FORMAT_YUYV },
> + { __DRI_IMAGE_FOURCC_UYVY, __DRI_IMAGE_FORMAT_UYVY,
> +__DRI_IMAGE_COMPONENTS_Y_UXVX,PIPE_FORMAT_UYVY },
> };
>
> static const struct dri2_format_mapping *
>
Looks good to me, though I'm no expert on plan
On Monday, February 25, 2019 11:01:33 AM PST Pohjolainen, Topi wrote:
> On Mon, Feb 25, 2019 at 10:32:27AM -0800, Kenneth Graunke wrote:
> > On Monday, February 25, 2019 6:33:11 AM PST Pohjolainen, Topi wrote:
> > > On Thu, Nov 01, 2018 at 08:04:21PM -0700, Ken
On Monday, February 25, 2019 6:33:11 AM PST Pohjolainen, Topi wrote:
> On Thu, Nov 01, 2018 at 08:04:21PM -0700, Kenneth Graunke wrote:
> > This implements virtually all documented PIPE_CONTROL restrictions
> > in a centralized helper. You now simply ask for the operatio
On Thursday, February 21, 2019 8:55:31 AM PST Jason Ekstrand wrote:
> Copy+paste error. It was supposed to test cull and not clip.
>
> Fixes: 4e69fba534e "nir: Rewrite lower_clip_cull_distance_arrays..."
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109717
ted patches
to Iris which made it into the original MR:
Kenneth Graunke (732)
Jordan Justen (14)
Dave Airlie (13)
Chris Wilson (12)
Rafael Antognolli (8)
Jason Ekstrand (7)
Caio Marcelo de Oliveira Filho (3)
Andre Heider (2)
Rhys Kidd (1)
Sagar Ghuge (1)
Tapani
On Tuesday, February 19, 2019 10:08:13 AM PST Ville Syrjälä wrote:
> On Tue, Feb 19, 2019 at 09:36:14AM -0800, Rodrigo Vivi wrote:
> > On Mon, Feb 18, 2019 at 04:54:34PM +1100, Jonathan Gray wrote:
> > > Compared to linux and libdrm Mesa is missing a VLV and ICL id.
> > >
> > > 0x0f30
> > >
lways robust enough to cope with the conflicting state.
>
> v2: Export brw_reset_state() to improve the amount of state we clobber
> on return to a starting context. (Kenneth)
>
> Cc: Kenneth Graunke
> ---
> The intent was to refactor the existing brw_reset_state() out of
> brw_in
On Saturday, February 16, 2019 4:41:30 AM PST Chris Wilson wrote:
> Introduce a new debug option to wilfully cause the GPU to hang and for
> the kernel to accuse of being neglectful.
> ---
> src/intel/Makefile.sources| 2 +
> src/intel/common/gen_debug.c |
gt; continue on fairly oblivious.
>
> To make wedging even more likely, we use a new "no recovery" context
> parameter that tells the kernel to not even attempt to replay any
> batches in flight against the default context image, as experience shows
> the HW is not always rob
On Thursday, February 7, 2019 3:35:01 AM PST andrey simiklit wrote:
> ping. the piglit test was pushed)
>
> Thanks,
> Andrii.
I landed this today. Thanks!
--Ken
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev
instr->num_components);
>
Good catch, thanks so much for the fix! I'm running it through a quick
set of testing (though it looks obviously correct), assuming that all
comes back green I'll push this shortly.
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/189
Here's a series that ports st/mesa's built-in shaders for various things
from TGSI to NIR. For drivers which prefer NIR, we use the new direct
versions rather than using tgsi_to_nir.
I've tested Piglit on radeonsi using R600_DEBUG=nir,
On Monday, January 28, 2019 11:29:00 AM PST Ilia Mirkin wrote:
> A few thoughts. Given past experience, I don't really expect these to
> have any serious impact on the direction taken, but I also don't want
> to just sit brooding in silence. Please note that full time/paid
> contributors probably
es for drivers that support
> transform feedback."
>
> I also think this should have a Fixes tag:
>
> Fixes: d644698b443 ("gallium: Add the ability to query a single
> pipeline statistics counter")
>
> With those things
On Wednesday, January 16, 2019 11:38:05 PM PST Erik Faye-Lund wrote:
> On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote:
> > All,
> >
> > The mesa project has now hit 100 merge requests (36 are still open).
> > I (and I'm sure others) would be curious to hear people's initial
> > thoughts
On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote:
> I think I kind of like having "mem" be on external things. Shared is a
> little weird there because it never leaves the chip so is it mem or shader?
On Intel GPUs, "shared" maps to a concept called "Shared Local Memory".
So I
On Friday, January 11, 2019 9:32:20 AM PST Eric Anholt wrote:
> Jason Ekstrand writes:
>
> > On Fri, Jan 11, 2019 at 11:11 AM Kenneth Graunke
> > wrote:
> >
> >> On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote:
> >> > On Fri, J
On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote:
> On Fri, Jan 11, 2019 at 10:19 AM Kenneth Graunke wrote:
> > Those names (nir_var_func_local, nir_var_thread_local, and
> > nir_var_thread_global) make more sense to me than private/function.
> &g
On Wednesday, January 9, 2019 5:33:22 PM PST Ian Romanick wrote:
> On 1/8/19 9:57 PM, Kenneth Graunke wrote:
> > On Tuesday, December 4, 2018 10:26:43 AM PST Karol Herbst wrote:
> >> the naming is a bit confusing no matter how you look at it. Within SPIR-V
> >> "glo
On Tuesday, December 4, 2018 10:26:43 AM PST Karol Herbst wrote:
> the naming is a bit confusing no matter how you look at it. Within SPIR-V
> "global" memory is memory accessible from all threads. glsl "global" memory
> normally refers to shader thread private memory declared at global scope. As
On Tuesday, January 8, 2019 3:11:37 AM PST Chris Wilson wrote:
> Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > Hi Andrii,
> >
> > Although I think what these patches do makes sense, I think it's missing
> > the bigger picture.
> > There is a lot more state that gets lost if we have to
On Sunday, December 30, 2018 11:22:01 AM PST Matt Turner wrote:
> On Sun, Dec 30, 2018 at 1:01 AM Kenneth Graunke wrote:
> >
> > The original idea was that the backend compiler could eliminate
> > surfaces, so we would have it mark which ones are actually used,
> > th
The original idea was that the backend compiler could eliminate
surfaces, so we would have it mark which ones are actually used,
then shrink the binding table accordingly. Unfortunately, it's a
pretty blunt mechanism - it can only prune things from the end,
not the middle - since we decide the
rn all is to use "index". index <= 11 returns one. index == ~0 returns
> all. This is the least intrusive.
>
> st/mesa and gallium/hud always want to get one.
> st/nine and util/u_helpers always want to get all.
>
> Marek
>
> On Sat, Dec 15, 2018 at 4:45 AM Kenne
gt; old autotools setup.
>
> I'm definitely in favour:
> Acked-by: Eric Engestrom
Eric's reasoning here makes sense. In case there is anyone out there
who has been putting off trying Meson, this will properly exhort them
to try it, and identify any problems, yet still let them continue us
Nobody uses this, so let's drop it. This makes the helper callable
from places without a gl_program.
---
src/mesa/state_tracker/st_glsl_to_nir.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
Now that we always copy color, we can just use the util function.
---
src/mesa/state_tracker/st_cb_drawpixels.c | 38 +++
1 file changed, 11 insertions(+), 27 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
b/src/mesa/state_tracker/st_cb_drawpixels.c
DrawPixels lowering, for example, adds new varyings that need to be
accounted for in inputs_read. The earlier info gathering at link time
cannot account for this.
---
src/mesa/state_tracker/st_program.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/state_tracker/st_program.c
The glDrawPixels passthrough vertex shader copies position and texcoord
vertex attributes to varying outputs. It also optionally copies a third
gl_Color attribute, which sometimes is unnecessary. Until now, we've
compiled separate variants of the shader, one of which does this extra
copy, and
They're now identical, so we can just compile it once.
---
src/mesa/state_tracker/st_cb_bitmap.c | 27 +--
src/mesa/state_tracker/st_cb_drawpixels.c | 20 -
src/mesa/state_tracker/st_cb_drawpixels.h | 3 +++
src/mesa/state_tracker/st_context.h | 5
Dead since 2015 (commit 5142564734bd68f165b02e29e384ebbcf91cce38).
---
src/mesa/state_tracker/st_context.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_context.h
b/src/mesa/state_tracker/st_context.h
index 95133c7020f..78e962dec00 100644
---
On Saturday, December 15, 2018 9:10:46 AM PST Ilia Mirkin wrote:
> On Sat, Dec 15, 2018 at 4:45 AM Kenneth Graunke wrote:
> > Gallium handles pipeline statistics queries as a single query
> > (PIPE_QUERY_PIPELINE_STATISTICS) which returns a struct with 11 values.
> >
Gallium handles pipeline statistics queries as a single query
(PIPE_QUERY_PIPELINE_STATISTICS) which returns a struct with 11 values.
Sometimes it's useful to refer to each of those values individually,
rather than as a group. To avoid hardcoding numbers, we define a new
enum for each value.
We can now simply index into an array of uint64_t values to read or
write the result, based on the query's index. The structure is still
available and is interchangeable.
Cc: Roland Scheidegger
---
src/gallium/include/pipe/p_defines.h| 3 ++
src/mesa/state_tracker/st_cb_queryobj.c | 55
GL exposes separate queries for each pipeline statistics counter,
each of which return a single value. Gallium (and D3D) treats them
as a single query, PIPE_QUERY_PIPELINE_STATISTICS, which returns 11
values. Radeon hardware appears to query them all as a group, and
the CPU-side hook,
Gen9-10 have fewer than 4 subslices per slice, so they need this to be
rounded up. Gen11 isn't documented as needing this hack, and it can
also have more than 4 subslices, so the hack actually can break things.
---
src/mesa/drivers/dri/i965/brw_program.c | 2 +-
1 file changed, 1 insertion(+), 1
On Wednesday, December 12, 2018 9:17:38 AM PST Jason Ekstrand wrote:
> On Wed, Dec 12, 2018 at 11:09 AM Jason Ekstrand
> wrote:
>
> > On Tue, Dec 11, 2018 at 10:31 PM Kenneth Graunke
> > wrote:
> >
> >> When we first started using genxml, we decided to repres
On Wednesday, December 12, 2018 9:09:54 AM PST Jason Ekstrand wrote:
> On Tue, Dec 11, 2018 at 10:31 PM Kenneth Graunke
> wrote:
>
> > When we first started using genxml, we decided to represent MOCS as an
> > actual structure, and pack values. However, in man
On Thursday, December 13, 2018 5:00:43 PM PST Rafael Antognolli wrote:
> On Wed, Oct 31, 2018 at 04:27:31PM -0700, Kenneth Graunke wrote:
> > On Wednesday, October 31, 2018 11:15:28 AM PDT Rafael Antognolli wrote:
> > > On Tue, Oct 30, 2018 at 04:32:54PM -0700, Ken
When we first started using genxml, we decided to represent MOCS as an
actual structure, and pack values. However, in many places, it was more
convenient to use a numeric value rather than treating it as a struct,
so we added secondary setters in a bunch of places as well.
We were not entirely
load_register_imm and load_register_mem take the destination as the
first argument, so I'd like load_register_reg to do the same the sake
of consistency. Otherwise, reading sequences of mixed LRI/LRM/LRR is
needlessly confusing.
---
src/mesa/drivers/dri/i965/brw_conditional_render.c | 2 +-
On Monday, December 3, 2018 4:48:54 PM PST Jason Ekstrand wrote:
> Jordan has requested to be made an Owner of the mesa project. As much as I
> may be the guy who pushed to get everything set up, I don't want to do this
> sort of thing on my own. As such, I'm asking for some ACKs. If I can get
In the softpin world, surface state base address may be a fixed 64-bit
address (with no associated BO). It makes sense to store this in the
offset field. But it needs to be the full size.
We also update the clear color address to be consistently uint64_t
everywhere so we can continue passing
In i965, shader programs live in a single buffer, and every batch emits
a STATE_BASE_ADDRESS packet pointing to that buffer. This takes care of
pinning the buffer for the batch; from then on, we can use an offset.
In the upcoming Iris driver, shader programs can live in multiple
buffers, and
Drivers using softpin do not need (or have) relocations. The old
relocation interface is somewhat awkward and limiting.
In particular, brw_surface_reloc assumes that all SURFACE_STATEs will
exist in a single buffer, and only provides ss_offset. The driver is
supposed to implicitly know about
Vulkan and Gallium don't use Mesa's gl_program data structure, so they
can't poke at 'prog'. But we can simply use the copy of the shader info
stored with the NIR shader, which is guaranteed to exist.
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_vec4_gs_visitor.cpp | 2 +-
1 file
wonky, it only has "smooth point" limits,
which are actually round points...but it kind of conflates smooth and
multisampled...
On Saturday, November 17, 2018 6:57:04 AM PST Jason Ekstrand wrote:
> Do smaller point sizes make sense when multisampling?
>
> On November 17, 20
We advertise 1.0 as the minimum point width size, and we probably ought
to clamp gl_PointSize to the actual range we advertise ([1,255]). In
particular, we don't seem to rasterize any points if the shader outputs
a point size smaller than 1.0, and that seems rather sketchy.
This fixes Piglit's
This is all leftover from the i965 split.
---
src/mesa/drivers/dri/i915/intel_context.c | 2 --
src/mesa/drivers/dri/i915/intel_context.h | 1 -
src/mesa/drivers/dri/i915/intel_screen.c | 26 ---
src/mesa/drivers/dri/i915/intel_screen.h | 2 --
4 files changed, 31
On Thursday, November 15, 2018 11:16:09 PM PST Francisco Jerez wrote:
> Kenneth Graunke writes:
>
> > On Thursday, November 15, 2018 5:51:18 PM PST Francisco Jerez wrote:
> >> Anuj Phogat writes:
> >>
> >> > Use L3 configuration table specified in h
On Tuesday, November 13, 2018 2:33:59 PM PST Anuj Phogat wrote:
> L3 allocation table in h/w specification recommends using 4 KB
> granularity for programming allocation fields in L3CNTLREG.
>
> Signed-off-by: Anuj Phogat
> Cc: Kenneth Graunke
> Cc: Francisco Jerez
>
On Thursday, November 15, 2018 5:51:18 PM PST Francisco Jerez wrote:
> Anuj Phogat writes:
>
> > Use L3 configuration table specified in h/w specification.
> >
> > Signed-off-by: Anuj Phogat
> > Cc: Kenneth Graunke
> > Cc: Francisco Jerez
> > Cc:
On Tuesday, November 13, 2018 2:33:58 PM PST Anuj Phogat wrote:
> Use L3 configuration table specified in h/w specification.
>
> Signed-off-by: Anuj Phogat
> Cc: Kenneth Graunke
> Cc: Francisco Jerez
> Cc: Lionel Landwerlin
> ---
> src/intel/common/gen_l3_config.c |
It's shorter and will also be useful when I adjust cloning soon.
---
src/mesa/drivers/dri/i965/brw_cs.c | 6 +++---
src/mesa/drivers/dri/i965/brw_gs.c | 11 ++-
src/mesa/drivers/dri/i965/brw_tcs.c | 2 +-
src/mesa/drivers/dri/i965/brw_tes.c | 2 +-
src/mesa/drivers/dri/i965/brw_vs.c
This moves nir_shader_clone() to the driver-specific compile function,
rather than the shared src/intel/compiler code. This allows i965 to do
key-specific passes before calling brw_compile_*. Vulkan should not
need this cloning as it doesn't compile multiple variants.
We do need to continue
It's now called exactly once, and there's not really any distinction.
---
src/compiler/nir/nir_lower_clip.c | 76 ++-
1 file changed, 34 insertions(+), 42 deletions(-)
diff --git a/src/compiler/nir/nir_lower_clip.c
b/src/compiler/nir/nir_lower_clip.c
index
1 - 100 of 8470 matches
Mail list logo
