Re: [Mesa-dev] [PATCH] intel/blorp_blit: Fix max blit size for gen6
Guys... Stop reviewing patches on Christmas Eve...
On Dec 24, 2016 7:34 PM, "Kenneth Graunke" wrote:
> On Saturday, December 24, 2016 9:49:14 AM PST Jordan Justen wrote:
> > Fixes ES3-CTS.gtf.GL3Tests.framebuffer_blit.framebuffer_
> blit_functionality_stencil_blit
> >
> > Signed-off-by: Jordan Justen
> > ---
> > src/intel/blorp/blorp_blit.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
> > index 8abe3a8..1cbd940 100644
> > --- a/src/intel/blorp/blorp_blit.c
> > +++ b/src/intel/blorp/blorp_blit.c
> > @@ -1522,10 +1522,11 @@ static unsigned
> > get_max_surface_size(const struct gen_device_info *devinfo,
> > const struct blorp_params *params)
> > {
> > + const unsigned max = devinfo->gen >= 7 ? 16384 : 8192;
> > if (split_blorp_blit_debug && can_shrink_surfaces(params))
> > - return 16384 >> 4; /* A smaller restriction when debug is enabled
> */
> > + return max >> 4; /* A smaller restriction when debug is enabled */
> > else
> > - return 16384;
> > + return max;
> > }
> >
> > struct blt_axis {
> >
>
> Reviewed-by: Kenneth Graunke
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/blorp_blit: Fix max blit size for gen6
On Saturday, December 24, 2016 9:49:14 AM PST Jordan Justen wrote:
> Fixes
> ES3-CTS.gtf.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_stencil_blit
>
> Signed-off-by: Jordan Justen
> ---
> src/intel/blorp/blorp_blit.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
> index 8abe3a8..1cbd940 100644
> --- a/src/intel/blorp/blorp_blit.c
> +++ b/src/intel/blorp/blorp_blit.c
> @@ -1522,10 +1522,11 @@ static unsigned
> get_max_surface_size(const struct gen_device_info *devinfo,
> const struct blorp_params *params)
> {
> + const unsigned max = devinfo->gen >= 7 ? 16384 : 8192;
> if (split_blorp_blit_debug && can_shrink_surfaces(params))
> - return 16384 >> 4; /* A smaller restriction when debug is enabled */
> + return max >> 4; /* A smaller restriction when debug is enabled */
> else
> - return 16384;
> + return max;
> }
>
> struct blt_axis {
>
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
Re: [Mesa-dev] [PATCH] radv: return count of queue families written
On Sun, Dec 25, 2016 at 12:41 AM, Damien Grassart wrote:
> The Vulkan spec indicates that
> vkGetPhysicalDeviceQueueFamilyProperties() should overwrite
> pQueueFamilyPropertyCount with the number of structures actually
> written to pQueueFamilyProperties.
Reviewed-by: Bas Nieuwenhuizen
and pushed.
>
> Signed-off-by: Damien Grassart
> ---
> src/amd/vulkan/radv_device.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 47be5f743f..dcbb01547e 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -583,8 +583,10 @@ void radv_GetPhysicalDeviceQueueFamilyProperties(
> idx++;
> }
>
> - if (!all_queues)
> + if (!all_queues) {
> + *pCount = idx;
> return;
> + }
>
> if (pdevice->rad_info.compute_rings > 0 &&
> pdevice->rad_info.chip_class >= CIK) {
> if (*pCount > idx) {
> @@ -597,6 +599,7 @@ void radv_GetPhysicalDeviceQueueFamilyProperties(
> idx++;
> }
> }
> + *pCount = idx;
> }
>
> void radv_GetPhysicalDeviceMemoryProperties(
> --
> 2.11.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ttn: set ->info->num_ubos
On Sat, Dec 24, 2016 at 7:30 PM, Eric Anholt wrote: > Rob Clark writes: > >> For dealing w/ 32b vs 64b gpu addresses, I need to rework how we pass >> UBO buffer addresses to shader, and knowing up front the # of UBOs is >> useful. But I noticed ttn wasn't setting this. > > I'm surprised you're still using TTN. But: > > Reviewed-by: Eric Anholt yeah, re-working how I do arrays / indirect so I can vars->regs is still needed before I can switch to glsl_to_nir by default without getting a bunch of regressions or having to re-invent deref lowering.. :-( BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ttn: set ->info->num_ubos
Rob Clark writes: > For dealing w/ 32b vs 64b gpu addresses, I need to rework how we pass > UBO buffer addresses to shader, and knowing up front the # of UBOs is > useful. But I noticed ttn wasn't setting this. I'm surprised you're still using TTN. But: Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 98169] lm_sensors hud option crashes unigine heaven
https://bugs.freedesktop.org/show_bug.cgi?id=98169 Christoph Haag changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] anv: return count of queue families written
The Vulkan spec indicates that
vkGetPhysicalDeviceQueueFamilyProperties() should overwrite
pQueueFamilyPropertyCount with the number of structures actually
written to pQueueFamilyProperties.
Signed-off-by: Damien Grassart
---
src/intel/vulkan/anv_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 9245e5c878..81217e77c9 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -656,6 +656,7 @@ void anv_GetPhysicalDeviceQueueFamilyProperties(
.timestampValidBits = 36, /* XXX: Real value here */
.minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
};
+ *pCount = 1;
}
void anv_GetPhysicalDeviceMemoryProperties(
--
2.11.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/blorp_blit: Fix max blit size for gen6
Reviewed-by: Lionel Landwerlin
On 24/12/16 18:49, Jordan Justen wrote:
Fixes
ES3-CTS.gtf.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_stencil_blit
Signed-off-by: Jordan Justen
---
src/intel/blorp/blorp_blit.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
index 8abe3a8..1cbd940 100644
--- a/src/intel/blorp/blorp_blit.c
+++ b/src/intel/blorp/blorp_blit.c
@@ -1522,10 +1522,11 @@ static unsigned
get_max_surface_size(const struct gen_device_info *devinfo,
const struct blorp_params *params)
{
+ const unsigned max = devinfo->gen >= 7 ? 16384 : 8192;
if (split_blorp_blit_debug && can_shrink_surfaces(params))
- return 16384 >> 4; /* A smaller restriction when debug is enabled */
+ return max >> 4; /* A smaller restriction when debug is enabled */
else
- return 16384;
+ return max;
}
struct blt_axis {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: return count of queue families written
The Vulkan spec indicates that
vkGetPhysicalDeviceQueueFamilyProperties() should overwrite
pQueueFamilyPropertyCount with the number of structures actually
written to pQueueFamilyProperties.
Signed-off-by: Damien Grassart
---
src/amd/vulkan/radv_device.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 47be5f743f..dcbb01547e 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -583,8 +583,10 @@ void radv_GetPhysicalDeviceQueueFamilyProperties(
idx++;
}
- if (!all_queues)
+ if (!all_queues) {
+ *pCount = idx;
return;
+ }
if (pdevice->rad_info.compute_rings > 0 && pdevice->rad_info.chip_class
>= CIK) {
if (*pCount > idx) {
@@ -597,6 +599,7 @@ void radv_GetPhysicalDeviceQueueFamilyProperties(
idx++;
}
}
+ *pCount = idx;
}
void radv_GetPhysicalDeviceMemoryProperties(
--
2.11.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] ttn: set ->info->num_ubos
For dealing w/ 32b vs 64b gpu addresses, I need to rework how we pass
UBO buffer addresses to shader, and knowing up front the # of UBOs is
useful. But I noticed ttn wasn't setting this.
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index d01e458..a0b0d82 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -314,8 +314,11 @@ ttn_emit_declaration(struct ttn_compile *c)
file == TGSI_FILE_CONSTANT);
/* nothing to do for UBOs: */
- if ((file == TGSI_FILE_CONSTANT) && decl->Declaration.Dimension)
+ if ((file == TGSI_FILE_CONSTANT) && decl->Declaration.Dimension) {
+ b->shader->info->num_ubos =
+MAX2(b->shader->info->num_ubos, decl->Dim.Index2D);
return;
+ }
if ((file == TGSI_FILE_INPUT) || (file == TGSI_FILE_OUTPUT)) {
is_array = (is_array && decl->Declaration.Array &&
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel/blorp_blit: Fix max blit size for gen6
Fixes
ES3-CTS.gtf.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_stencil_blit
Signed-off-by: Jordan Justen
---
src/intel/blorp/blorp_blit.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
index 8abe3a8..1cbd940 100644
--- a/src/intel/blorp/blorp_blit.c
+++ b/src/intel/blorp/blorp_blit.c
@@ -1522,10 +1522,11 @@ static unsigned
get_max_surface_size(const struct gen_device_info *devinfo,
const struct blorp_params *params)
{
+ const unsigned max = devinfo->gen >= 7 ? 16384 : 8192;
if (split_blorp_blit_debug && can_shrink_surfaces(params))
- return 16384 >> 4; /* A smaller restriction when debug is enabled */
+ return max >> 4; /* A smaller restriction when debug is enabled */
else
- return 16384;
+ return max;
}
struct blt_axis {
--
2.10.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] gallium: add renderonly library
On 19 December 2016 at 21:50, Thierry Reding wrote: > On Mon, Dec 19, 2016 at 08:54:04PM +0100, Christian Gmeiner wrote: >> 2016-12-19 14:08 GMT+01:00 Thierry Reding : >> > On Wed, Nov 30, 2016 at 02:44:34PM +0100, Christian Gmeiner wrote: > [...] >> >> GALLIUM_WINSYS_CFLAGS = \ >> >> -I$(top_srcdir)/src \ >> >> -I$(top_srcdir)/include \ >> >> diff --git a/src/gallium/auxiliary/Makefile.am >> >> b/src/gallium/auxiliary/Makefile.am >> >> index 4a4a4fb..6b63cf1 100644 >> >> --- a/src/gallium/auxiliary/Makefile.am >> >> +++ b/src/gallium/auxiliary/Makefile.am >> >> @@ -20,6 +20,16 @@ libgallium_la_SOURCES = \ >> >> $(NIR_SOURCES) \ >> >> $(GENERATED_SOURCES) >> >> >> >> +if HAVE_LIBDRM >> >> + >> >> +AM_CFLAGS += \ >> >> + $(LIBDRM_CFLAGS) >> > >> > Same here. >> >> I just redone what other have done in that file. There are some if's >> in that file and I am unsure >> what to do here. > > Maybe Emil has a strong opinion here, I was really just nit-picking, so > feel free to leave this. > There's no strong policy for these, plus we have a mix of the two atm. I'm fine either way on the include/cflags, but if anyone has strong preference sure go ahead :-) Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] imx: gallium driver for imx-drm scanout driver
On 19 December 2016 at 21:19, Thierry Reding wrote:
> On Mon, Dec 19, 2016 at 04:04:34PM +, Emil Velikov wrote:
>> On Monday, 19 December 2016, Thierry Reding
>> wrote:
>>
>> > On Wed, Nov 30, 2016 at 02:44:36PM +0100, Christian Gmeiner wrote:
>> > [...]
>> > > +static struct pipe_screen *imx_open_render_node(struct renderonly *ro)
>> > > +{
>> > > + return etna_drm_screen_create_rendernode(ro);
>> > > +}
>> >
>> > Patch 2/3 never made it into my inbox for some reason, and had to find
>> > it in some archives. I'll have to resort to commenting on the code here.
>> > From what I saw, etna_drm_screen_create_rendernode() hard-codes the GPU
>> > render node (to /dev/dri/renderD128, I think). It's a little brittle for
>> > obvious reasons, but I think you might be able to get away with it,
>> > depending on the SoC.
>> >
>> > On Tegra we have a bunch of people that stick discrete GPUs into the
>> > PCIe slot and run a second instance of Nouveau on that. It's an
>> > interesting use-case, but it also has the drawback of creating a second
>> > renderD device. What's more, it uses the same kernel driver, so hard-
>> > coding the device node is going to give us a 50-50 chance on average
>> > that we get the right one. Back when I had written the original proposal
>> > I had also coded a heuristic that would walk sysfs and select the render
>> > node that was on the same bus as the card node. This was before Emil had
>> > removed the dependency on udev, but I've rewritten that code to work
>> > with Emil's drmDevice*() API, which needs some fleshing out[0].
>> >
>> > Out of curiosity, is this something that could happen on i.MX devices as
>> > well? Or even if not i.MX, I'm fairly sure that there are other SoCs
>> > that have a Vivante GPU and a PCI slot that people could use to stick
>> > big GPUs into, so you may run into the same issue eventually.
>>
>> Thanks Thierry for the nice write-up. Must admit that I was feeling a bit
>> lazy.
>>
>> Considering the ~ok odds and the fact that we don't have platform support
>> for the drm*Device helpers I'm inclined to have this fixed after the merge.
>>
>> Let's have etna and(?) tegra and sort bugs during the RCs ;-)
>
> I'm fine if you want etnaviv as-is. I personally would want to hold off
> on Tegra for a wee bit longer. Let's see if Alex has a strong opinion.
>
> What are your requirements for release? Will you be freezing the libdrm
> dependency during RCs? I've got most of the patches ready to make this
> work reliably on Tegra, though I'd still have to port my patches to
> Christian's renderonly library.
>
I'm open to libdrm bump during RC1/RC2 and less so during the later stages.
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
