Jason Ekstrand writes:
> You can have a full reviewed-by
You're too kind :-)
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Jason Ekstrand writes:
>> + if (allocator)
>> + alloc = allocator;
>> + else
>> + alloc = &device->instance->alloc;
>>
>
> This is what vk_alloc2 is for. :-)
...
> And vk_free2
...
> This isn't needed if you're using vk_alloc2
Yeah, but I need to pass the allocator down to the wsi co
On June 19, 2018 22:16:37 "Keith Packard" wrote:
Jason Ekstrand writes:
I don't think I have any more comments on this patch. It's gross but I
think it should work.
I'll mark you down as 'Acked-by' then. Neither of us loves the
implementation; I'll see about creating the kernel infrastruc
Jason Ekstrand writes:
> I don't think I have any more comments on this patch. It's gross but I
> think it should work.
I'll mark you down as 'Acked-by' then. Neither of us loves the
implementation; I'll see about creating the kernel infrastructure
necessary to supplant it.
--
-keith
signat
Hi,
It seems that dlist.c is getting popular again, but can't we generate
most of dlist.c using the api files?
Probably saves a lot of typing, copying and pasting in the long run.
Should also be less error prone in the long run.
Not that I think code generation is required, but I believe it would
Jason Ekstrand writes:
> They're being used as helpers and they're actually kind-of nice for
> that.
Sounds good. I hadn't actually looked at the details; just saw the
functions going away in the initializers.
--
-keith
signature.asc
Description: PGP signature
___
Jason Ekstrand writes:
> C99 guarantees that, one one field is initialized with a designated
> initializer then all fields not explicitly initialized get
> zero-initialized. I can add it if you'd like none the less.
Yeah, I just thought it would be clearer to the reader if the field were
explic
Jason Ekstrand writes:
> Thoughts?
You've looked at the code more closely than I have; please feel free to
leave it if you think it would seem worse as separate functions.
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing list
Reviewed-by: Timothy Arceri
On 12/05/18 19:40, Alejandro Piñeiro wrote:
From: Neil Roberts
Previously when setting up a uniform it would try to walk the uniform
storage slots and find one that matches the name of the given
variable. However, each variable already has a location which is an
in
I'm still unsure about some design decisions but in the name of
progressing this work this patch is:
Reviewed-by: Timothy Arceri
We can always rework things later if need be.
On 12/05/18 19:40, Alejandro Piñeiro wrote:
From: Eduardo Lima Mitev
This function will be the entry point for link
Reviewed-by: Timothy Arceri
On 12/05/18 19:40, Alejandro Piñeiro wrote:
From: Neil Roberts
This is based on link_uniform_initializers.cpp.
v2: move from compiler/nir to compiler/glsl (Timothy Arceri)
---
src/compiler/Makefile.sources | 1 +
.../glsl/gl_nir_link_unif
Jason Ekstrand writes:
>> + if (!prop)
>> + continue;
>> + if (prop->flags & DRM_MODE_PROP_ENUM) {
>> + if (!strcmp(prop->name, "DPMS"))
>> +connector->dpms_property = drm_connector->props[p];
>>
>
> break?
Not break; I need to free the property. However, a
On Tue, Jun 19, 2018 at 11:00 PM, Jordan Justen
wrote:
> On 2018-06-18 17:48:26, Ilia Mirkin wrote:
>> On Mon, Jun 18, 2018 at 7:19 PM, Jason Ekstrand wrote:
>> > On Mon, Jun 18, 2018 at 3:57 PM, Ilia Mirkin wrote:
>> >>
>> >> Not sure how much voting power I have, but I really like Erik's versi
Reviewed-by: Marek Olšák
Marek
On Fri, Jun 15, 2018 at 6:06 PM, Rhys Perry
wrote:
> Signed-off-by: Rhys Perry
> ---
> src/compiler/glsl/ast_to_hir.cpp | 5 +
> src/compiler/glsl/glsl_parser_extras.cpp | 1 +
> src/compiler/glsl/glsl_parser_extras.h | 7 +++
> src/mesa/main
Reviewed-by: Marek Olšák
Marek
On Fri, Jun 15, 2018 at 6:06 PM, Rhys Perry
wrote:
> Signed-off-by: Rhys Perry
> ---
> src/mesa/state_tracker/st_extensions.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src/mesa/state_tracker/st_extension
You forgot to update a few PIPE_SHADER_CAP occurences. Also, documentation
of all PIPE_CAPs is typically added into screen.rst. Other than those:
Reviewed-by: Marek Olšák
Marek
On Fri, Jun 15, 2018 at 6:06 PM, Rhys Perry
wrote:
> Signed-off-by: Rhys Perry
> ---
> src/gallium/drivers/etnaviv
For the series:
Reviewed-by: Marek Olšák
Marek
On Fri, Jun 8, 2018 at 8:19 AM, Timothy Arceri
wrote:
> ---
> src/util/drirc | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/util/drirc b/src/util/drirc
> index 574374418fd..ee0133f4f40 100644
> --- a/src/util/drirc
> +++ b/src/util
On 2018-06-18 17:48:26, Ilia Mirkin wrote:
> On Mon, Jun 18, 2018 at 7:19 PM, Jason Ekstrand wrote:
> > On Mon, Jun 18, 2018 at 3:57 PM, Ilia Mirkin wrote:
> >>
> >> Not sure how much voting power I have, but I really like Erik's version at
> >>
> >> https://codepen.io/kusma/pen/vrXppL
> >>
> >>
On Tue, Jun 19, 2018 at 6:22 PM, Keith Packard wrote:
> Jason Ekstrand writes:
>
> > I suppose we probably shouldn't worry about current_time being greater
> than
> > INT64_MAX? I guess if that happens we have pretty big problems...
>
> Nope, we've already given up on that working -- it's a cou
---
src/mesa/main/extensions_table.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 1c55df8a228..423f22b4657 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -76,7
---
src/mesa/main/dlist.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index 0eb665e25e7..57ece6c30e0 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -523,6 +523,9 @@ typedef enum
/* ARB_
This is required for fp64 to be enabled in compat profile.
---
src/mesa/main/dlist.c | 514 ++
1 file changed, 514 insertions(+)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index b0fbc17d017..0eb665e25e7 100644
--- a/src/mesa/main/dlist.c
+++
I managed to miss these two in my last pass at this.
---
src/mesa/main/get_hash_params.py | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 83136108e95..618e306e509 100644
--- a/src/mesa/main/get_hash_
This is required so we can enable fp64 support in compat profile.
---
src/mapi/glapi/gen/apiexec.py | 36 +--
src/mesa/main/dlist.c | 493 ++
2 files changed, 511 insertions(+), 18 deletions(-)
diff --git a/src/mapi/glapi/gen/apiexec.py b/src/mapi/glapi/ge
---
src/mapi/glapi/gen/apiexec.py| 16
src/mesa/main/extensions_table.h | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/mapi/glapi/gen/apiexec.py b/src/mapi/glapi/gen/apiexec.py
index 00c80171274..e69c6b4df16 100644
--- a/src/mapi/glapi/gen/apiexec.
Jason Ekstrand writes:
> I suppose we probably shouldn't worry about current_time being greater than
> INT64_MAX? I guess if that happens we have pretty big problems...
Nope, we've already given up on that working -- it's a couple hundred
years of system uptime. Neither of us have any concerns
this patch adds support for a20x, which has some differences with a220:
-no VGT_MAX_VTX_INDX register
-no CLEAR_COLOR register
-set RB_BC_CONTROL in restore (hangs without)
-different CP_DRAW_INDX format
tested with kmscube and glmark2 scenes, on par with a220
Signed-off-by: Jonathan Marek
---
blend can be NULL, so check for that
Signed-off-by: Jonathan Marek
---
src/gallium/drivers/freedreno/a2xx/fd2_emit.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
b/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
index 9c
Signed-off-by: Jonathan Marek
---
src/gallium/drivers/freedreno/a2xx/fd2_program.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_program.c
b/src/gallium/drivers/freedreno/a2xx/fd2_program.c
index 9a77457251..834a7c7fcd 100644
--- a/src/gallium/drive
blend can be NULL, so check for that
Signed-off-by: Jonathan Marek
---
src/gallium/drivers/freedreno/a2xx/fd2_emit.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
b/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
index 9c
This extension is required to support EXT_display_control as it offers a
way to query whether the vblank counter is supported. Internally, it is
implemented using a fake MESA extension which provides a chain-in to
GetSurfaceCapabilities2KHR which contains the one added field. This has
the advanta
On Tue, Jun 19, 2018 at 5:11 PM, Keith Packard wrote:
> Jason Ekstrand writes:
>
> > Sometimes the best way to review a patch is with another patch. :-) I'm
> > not sure what you think of this approach but I didn't really relish the
> > idea of having 3 get_capabilities entrypoints. With these
On Tue, Jun 19, 2018 at 5:09 PM, Keith Packard wrote:
> Jason Ekstrand writes:
>
> > Instead, we can just use get_capabilities2. This way back-ends only
> > have to implement one hook.
>
> Yeah, this looks nice. Are you going to remove the unused functions at
> some point?
>
They're being used
On Tue, Jun 19, 2018 at 5:36 PM, Keith Packard wrote:
> Jason Ekstrand writes:
>
> > I still don't really like this but I agree that this code really should
> not
> > be getting hit very often so it's probably not too bad. Maybe one day
> > we'll be able to drop the non-syncobj paths entirely.
On Tue, Jun 19, 2018 at 5:01 PM, Keith Packard wrote:
> Jason Ekstrand writes:
>
> I see two styles here -- get_physical_device_display_properties* both
> use a helper function that takes a pointer to either of the property
> returns while get_physical_device_display_plane_properties* and
> get_
Jason Ekstrand writes:
> I still don't really like this but I agree that this code really should not
> be getting hit very often so it's probably not too bad. Maybe one day
> we'll be able to drop the non-syncobj paths entirely. Wouldn't that be
> nice.
I agree. What I want to have is kernel-s
On Thu, Jun 14, 2018 at 7:52 PM, Keith Packard wrote:
> This extension provides fences and frame count information to direct
> display contexts. It uses new kernel ioctls to provide 64-bits of
> vblank sequence and nanosecond resolution.
>
> v2: Adopt Jason Ekstrand's coding conventions
>
>
Sorry for the flood of comments. Most of it's pretty trivial. The one
that has me the most concerned is the random appearence of 0.1s in some
strange places. Other than that, I'm reasonably happy with it.
On Thu, Jun 14, 2018 at 7:52 PM, Keith Packard wrote:
> This extension provides fences a
Jason Ekstrand writes:
> Sometimes the best way to review a patch is with another patch. :-) I'm
> not sure what you think of this approach but I didn't really relish the
> idea of having 3 get_capabilities entrypoints. With these two patches,
> we're now down to one. In order to implement VK_
Jason Ekstrand writes:
> Instead, we can just use get_capabilities2. This way back-ends only
> have to implement one hook.
Yeah, this looks nice. Are you going to remove the unused functions at
some point?
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
_
Jason Ekstrand writes:
I see two styles here -- get_physical_device_display_properties* both
use a helper function that takes a pointer to either of the property
returns while get_physical_device_display_plane_properties* and
get_display_mode_properties* open-code things.
I'm easy with which sty
On Tue, Jun 19, 2018 at 02:45:22PM +0100, Lionel Landwerlin wrote:
> From: Scott D Phillips
>
> v2: by Lionel
> Fix memfd_create compilation issue
> Fix pml4 address stored on 32 instead of 64bits
> Return no buffer if first ppgtt page is not mapped
>
> Signed-off-by: Lionel Landwerl
Patch is
Reviewed-by: Rafael Antognolli
On Tue, Jun 19, 2018 at 02:45:19PM +0100, Lionel Landwerlin wrote:
> Now that we're softpinning the address of our BOs in anv & i965, the
> addresses selected start at the top of the addressing space. This is a
> problem for the current implementation of a
I still don't really like this but I agree that this code really should not
be getting hit very often so it's probably not too bad. Maybe one day
we'll be able to drop the non-syncobj paths entirely. Wouldn't that be
nice. In the mean time, this is probably fine. I did see one issue below
with
Whichever way this goes, is it possible to have the pre-announce include a
link to the git repo/branch in question?
This way, even if it's not part of the main repo, people can easily find it
and check out the pre-release in full.
FWIW: An advantage of not requiring it to be in the main repo is t
When VK_USE_PLATFORM_XLIB_XRANDR_EXT is defined, vulkan.h includes
X11/extensions/Xrandr.h for the RROutput typedef which is used in
the vkGetRandROutputDisplayEXT interface.
Make sure we have the required header by checking during the build,
and also set CFLAGS to point at the right directory.
W
On Thu, May 31, 2018 at 10:39 AM Matt Turner wrote:
>
> On Fri, May 25, 2018 at 3:28 PM, Matt Turner wrote:
> >> 1-6, 8-20 are
> >>
> >> Reviewed-by: Matt Turner
> >
> > 7, 22-31 are too.
>
> 34-49 are too.
21 landed separately. 32, 33, 51-53 are also
Reviewed-by: Matt Turner
so I think you'
On Thu, May 31, 2018 at 10:54 AM Francisco Jerez wrote:
>
> Matt Turner writes:
>
> > On Fri, May 25, 2018 at 8:08 PM, Jason Ekstrand
> > wrote:
> >> On May 25, 2018 15:28:22 Matt Turner wrote:
> >>
> >>> On Thu, May 24, 2018 at 2:56 PM, Jason Ekstrand
> >>> wrote:
>
> From: Francis
On Wed, May 30, 2018 at 4:25 PM Jason Ekstrand wrote:
>
> On g4x through Sandy Bridge, src1 (the coordinates) of the PLN
> instruction is required to be an even register number. When it's odd
> (which can happen with SIMD32), we have to emit a LINE+MAC combination
> instead. Unfortunately, we ca
On Tue, Jun 19, 2018 at 11:40:30AM -0700, Rafael Antognolli wrote:
> On Tue, Jun 19, 2018 at 02:45:17PM +0100, Lionel Landwerlin wrote:
> > Now that we rely on mmap of the data to parse, we can't process the
> > standard input anymore.
>
> Didn't we rely on mmap of the data since forever?
Oh, I t
A case of making things worse while trying to fix something minor ...
Fixes: ef79457004e "radv: Merge the flush bits of CMASK & DCC clear."
---
src/amd/vulkan/radv_meta_clear.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/ra
For some reason I always have trouble finding the docs about this.
Still, it looks correct according to the docs, and it also seems to be
matching what I see in aubdump since "tools/intel_aubdump: Simulate
"enhanced execlist" submission for gen11+".
Reviewed-by: Rafael Antognolli
On Tue, Jun 19,
Jason Ekstrand writes:
> Looks good. Passes the CTS. Push it!
All done. Now just two more series to go in this set :-)
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freed
On Tue, Jun 19, 2018 at 1:56 PM, Keith Packard wrote:
> Jason Ekstrand writes:
>
> > 1) We weren't setting planeReorderPossible at all and we were using 0
> > instead of VK_FALSE (they're the same but we should use the enum) for
> > persistentContent
> > 2) We weren't advertising disconnected
Jason Ekstrand writes:
> 1) We weren't setting planeReorderPossible at all and we were using 0
> instead of VK_FALSE (they're the same but we should use the enum) for
> persistentContent
> 2) We weren't advertising disconnected connectors via
> GetPhysicalDeviceDisplayProperties but were return
https://bugs.freedesktop.org/show_bug.cgi?id=106151
--- Comment #18 from pritzl3...@gmail.com ---
Created attachment 140234
--> https://bugs.freedesktop.org/attachment.cgi?id=140234&action=edit
Savegame ROTTR
--
You are receiving this mail because:
You are the assignee for the bug.
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=106151
--- Comment #17 from pritzl3...@gmail.com ---
(In reply to Samuel Pitoiset from comment #16)
> (In reply to pritzl3452 from comment #15)
> > Hi Alex,
> >
> > I gave it a try now with the new update to ROTTR and the game still hangs in
> > the sa
On Tue, Jun 19, 2018 at 02:45:17PM +0100, Lionel Landwerlin wrote:
> Now that we rely on mmap of the data to parse, we can't process the
> standard input anymore.
Didn't we rely on mmap of the data since forever?
> This isn't much of a big deal because we have in-process batch decoder
> (run with
Reviewed-by: Rafael Antognolli
On Tue, Jun 19, 2018 at 02:45:16PM +0100, Lionel Landwerlin wrote:
> These memory offsets are stored in the gen_batch_decode_ctx.
>
> Signed-off-by: Lionel Landwerlin
> ---
> src/intel/tools/aubinator.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git
On Mon, Jun 18, 2018 at 12:56 PM, Dylan Baker wrote:
> Quoting Juan A. Suarez Romero (2018-06-18 00:22:02)
>> On Fri, 2018-06-15 at 12:47 -0400, Ilia Mirkin wrote:
>> > On Fri, Jun 15, 2018 at 12:36 PM, Dylan Baker wrote:
>> > > I don't even understand why we make these announcements TBH. I have
Reviewed-by: Lionel Landwerlin
On 19/06/18 16:05, Eric Engestrom wrote:
Signed-off-by: Eric Engestrom
---
src/intel/tools/aubinator.c | 16
1 file changed, 16 deletions(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index e4fb8adada354253143c..a4
On 19/06/18 16:05, Eric Engestrom wrote:
Signed-off-by: Eric Engestrom
---
src/intel/tools/aubinator.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index c8d79ae377d68285bd1e..e4fb8adada354253143c 100644
--- a/src/intel/tools/au
Quoting Daniel Stone (2018-06-19 08:47:13)
> Hi Dylan,
> On Tue, 19 Jun 2018 at 16:42, Dylan Baker wrote:
> > Historical artifact. When I created the proposed branch we didn't have a
> > policy
> > of putting it on master instead of a personal repo, and we were discussing a
> > transition to gitl
Signed-off-by: Eric Engestrom
---
src/intel/tools/aubinator.c | 16
1 file changed, 16 deletions(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index e4fb8adada354253143c..a4bc7b7aa12132a2d451 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/to
Signed-off-by: Eric Engestrom
---
src/intel/tools/aubinator.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index c8d79ae377d68285bd1e..e4fb8adada354253143c 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@
On Tuesday, 2018-06-19 06:42:24 -0700, Jason Ekstrand wrote:
> Do we test 915g in CI? I thought we tested 915 classic.
Oh, I didn't think of that, good point, I don't know how the CI
actually builds mesa.
Is that something I can see somewhere?
>
> On June 19, 2018 02:44:20 Eric Engestrom wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=106843
--- Comment #6 from Alex Granni ---
Ping.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=106843
Alex Granni changed:
What|Removed |Added
Summary|Cannot build osmesa with|Cannot build osmesa with
https://bugs.freedesktop.org/show_bug.cgi?id=106843
Alex Granni changed:
What|Removed |Added
CC||fdo-b...@engestrom.ch
--
You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=106843
--- Comment #5 from Alex Granni ---
Eric, I tried that branch but it's far from being in working state. When I
attempt to build it, it tries to find pkg-config. This doesn't make sense for a
MSVC build. As far as I know that's a Linux, MSYS2 and
https://bugs.freedesktop.org/show_bug.cgi?id=106151
--- Comment #16 from Samuel Pitoiset ---
(In reply to pritzl3452 from comment #15)
> Hi Alex,
>
> I gave it a try now with the new update to ROTTR and the game still hangs in
> the same way.
Can you explain how to reproduce? Maybe you can also
On Tue, Jun 19, 2018 at 9:38 AM, Rob Clark wrote:
> On Tue, Jun 19, 2018 at 9:09 AM, Ilia Mirkin wrote:
>> On Tue, Jun 19, 2018 at 8:53 AM, Rob Clark wrote:
>>> All of ARB_gpu_shader5 is most certainly not required for GLES 3.1
>>> (most of it is in OES_gpu_shader5 on top of GLES 3.1).
>>>
>>> S
Hi Dylan,
On Tue, 19 Jun 2018 at 16:42, Dylan Baker wrote:
> Historical artifact. When I created the proposed branch we didn't have a
> policy
> of putting it on master instead of a personal repo, and we were discussing a
> transition to gitlab. I also seem to remember that the gitlab doesn't all
Quoting Juan A. Suarez Romero (2018-06-19 00:08:27)
> On Fri, 2018-06-15 at 09:36 -0700, Dylan Baker wrote:
> > Quoting Juan A. Suarez Romero (2018-06-15 07:26:18)
> > > On Thu, 2018-06-14 at 10:16 -0700, Dylan Baker wrote:
> > > > Quoting Bas Nieuwenhuizen (2018-06-14 09:21:49)
> > > > > On Thu, J
v2: reword comment about lower_helper_invocations to be more clear
that it might not work on all hardware
v3: add special variant of load_sample_id which does not imply per-
sample shading
Signed-off-by: Rob Clark
---
Yeah, new intrinsic name is a bit funny sounding, but I couldn't
think
Hello gents,
On 19 June 2018 at 14:34, Tomasz Figa wrote:
>> --- a/src/gallium/auxiliary/Makefile.am
>> +++ b/src/gallium/auxiliary/Makefile.am
>> @@ -21,6 +21,10 @@ libgallium_la_SOURCES = \
>> $(NIR_SOURCES) \
>> $(GENERATED_SOURCES)
>>
>> +if HAVE_PLATFORM_ANDROID
>> +libgalli
---
.../swr/rasterizer/jitter/builder_gfx_mem.cpp | 13 +
.../drivers/swr/rasterizer/jitter/builder_gfx_mem.h | 6 ++
2 files changed, 19 insertions(+)
diff --git a/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.cpp
b/src/gallium/drivers/swr/rasterizer/jitter/bu
From: Vinson Lee
Fix build error after llvm-7.0svn r332881 ("CodeGen: Add a dwo output
file argument to addPassesToEmitFile and hook it up to dwo output.").
CXX rasterizer/jitter/libmesaswr_la-JitManager.lo
rasterizer/jitter/JitManager.cpp:368:93: error: too few arguments to function
cal
- Functionality replaced with emulated intrinsics
- Fixes Bug 106558
---
.../jitter/functionpasses/lower_x86.cpp | 40 +++
1 file changed, 40 insertions(+)
diff --git
a/src/gallium/drivers/swr/rasterizer/jitter/functionpasses/lower_x86.cpp
b/src/gallium/drivers/swr/rasteri
---
.../swr/rasterizer/jitter/JitManager.cpp | 133 ++--
.../swr/rasterizer/jitter/builder_gfx_mem.cpp | 90 +
.../swr/rasterizer/jitter/builder_gfx_mem.h | 101 +-
.../jitter/functionpasses/lower_x86.cpp | 189 +-
4 files changed, 260 insertio
These code changes were made in between some of the formatting changes.
Unforunately we do have another formatting patch coming in after this,
but I will keep that separate.
These patches are primarily focused on enhancing the BuilderGfxMem in our
internal rasterizer and to support changes in the
Having random data in there is probably not the best.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 22 --
src/amd/vulkan/radv_meta_clear.c | 4 ++--
src/amd/vulkan/radv_private.h| 8
3 files changed, 26 insertions(+), 8 deletions(-)
di
Similar to the clear color values.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 35 ++--
src/amd/vulkan/radv_meta_clear.c | 6 +++---
src/amd/vulkan/radv_private.h| 8
3 files changed, 27 insertions(+), 22 deletions(-)
diff --g
This might eventually skip some useless DCC decompression
passes.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index ccaab63b84b..7d64e8ce003 100644
--
Hello,
Thanks for a fast feedback.
I have created new patch:
"i965/gen6/gs: Handle case where a GS doesn't allocate VUE"
which contains all fixes.
Regards,
Andrii.
On Tue, Jun 19, 2018 at 3:16 PM, Iago Toral wrote:
> Hi Andrii,
>
> thanks for the fix!
>
> Kenneth, this patch makes it so that w
We can not use the VUE Dereference flags combination for EOT
message under ILK and SNB because the threads are not initialized
there with initial VUE handle unlike Pre-IL.
So to avoid GPU hangs on SNB and ILK we need
to avoid usage of the VUE Dereference flags combination.
(Was tested only on SNB b
Signed-off-by: Lionel Landwerlin
---
src/intel/Makefile.am |2 +
src/intel/tools/intel_dump_gpu.c | 1313 +
src/intel/tools/intel_dump_gpu.in | 107 +++
src/intel/tools/meson.build | 18 +
4 files changed, 1440 insertions(+)
create mode 10064
Signed-off-by: Lionel Landwerlin
---
src/intel/tools/intel_aub.h | 2 +-
src/intel/tools/intel_dump_gpu.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel/tools/intel_aub.h b/src/intel/tools/intel_aub.h
index 2888515048f..74ca26ab9bb 100644
--- a/src/intel/too
Signed-off-by: Lionel Landwerlin
---
src/intel/dev/gen_device_info.c | 47 ++---
src/intel/dev/gen_device_info.h | 5
2 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
index 8e9713298
Scott added new stuff in IGT.
Signed-off-by: Lionel Landwerlin
---
src/intel/tools/intel_aub.h | 26 ++
1 file changed, 26 insertions(+)
diff --git a/src/intel/tools/intel_aub.h b/src/intel/tools/intel_aub.h
index 5f0aba8e68e..9ca548edaf3 100644
--- a/src/intel/tools/int
We already embed the headers, no need to redefine defines/structs.
Signed-off-by: Lionel Landwerlin
---
src/intel/tools/intel_dump_gpu.c | 30 +-
1 file changed, 1 insertion(+), 29 deletions(-)
diff --git a/src/intel/tools/intel_dump_gpu.c b/src/intel/tools/intel_dum
From: Scott D Phillips
Reviewed-by: Lionel Landwerlin
---
src/intel/common/gen_batch_decoder.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/src/intel/common/gen_batch_decoder.c
b/src/intel/common/gen_batch_decoder.c
index 3852f32de36..2b6978da92d 1006
From: Scott D Phillips
For gen8+, write out PPGTT tables in aub files so that full 48-bit
addresses can be serialized.
v2: Fix handling of `end` index in map_ppgtt
Signed-off-by: Scott D Phillips
Signed-off-by: Lionel Landwerlin
Cc: Jordan Justen
---
src/intel/tools/intel_aub.h | 3 +
Signed-off-by: Lionel Landwerlin
---
src/intel/tools/aubinator.c | 82 -
1 file changed, 54 insertions(+), 28 deletions(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 3f9047e69a8..0438f96cd1b 100644
--- a/src/intel/tools/aubina
From: Scott D Phillips
v2: by Lionel
Fix memfd_create compilation issue
Fix pml4 address stored on 32 instead of 64bits
Return no buffer if first ppgtt page is not mapped
Signed-off-by: Lionel Landwerlin
---
src/intel/tools/aubinator.c | 76 -
1
With PPGTT mappings, our aubinator implementation can be quite slow if
we request a buffer that doesn't exist. Instead of doing a PPGTT walk
for invalid addresses (0 lengths), wait until we're sure we want to
decode the data.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Rafael Antognolli
---
s
Signed-off-by: Lionel Landwerlin
Reviewed-by: Rafael Antognolli
---
src/intel/common/gen_batch_decoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/common/gen_batch_decoder.c
b/src/intel/common/gen_batch_decoder.c
index 81d8298c28b..fc0ff95a476 100644
--- a/sr
Now that we're softpinning the address of our BOs in anv & i965, the
addresses selected start at the top of the addressing space. This is a
problem for the current implementation of aubinator which uses only a
40bit mmapped address space.
This change keeps track of all the memory writes from the a
We use memfd to store physical pages as they get read/written to and
the GGTT entries translating virtual address to physical pages.
Based on a commit by Scott Phillips.
Signed-off-by: Lionel Landwerlin
---
src/intel/tools/aubinator.c | 256 ++--
1 file changed,
These memory offsets are stored in the gen_batch_decode_ctx.
Signed-off-by: Lionel Landwerlin
---
src/intel/tools/aubinator.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index c8d79ae377d..949ba96e556 100644
--- a/src/intel/to
1 - 100 of 138 matches
Mail list logo
