On Fri, Nov 16, 2018 at 2:52 PM Francisco Jerez wrote:
>
> Anuj Phogat writes:
>
> > On Fri, Nov 16, 2018 at 6:21 AM Eero Tamminen
> > wrote:
> >>
> >> Hi,
> >>
> >> On 16.11.2018 10.33, Francisco Jerez wrote:
> >> > Kenneth Graunke writes:
> >> [...]
> >> >> Perhaps we'll get both configs
From: Marek Olšák
Cc: 18.2 18.3
---
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
index f32bbd9d086..b20d702670d 100644
---
From: Marek Olšák
Cc: 18.2 18.3
---
src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
index f49fb47b80e..3ee38b8a79f 100644
---
Signed-off-by: Jonathan Marek
---
src/gallium/drivers/freedreno/drm/freedreno_drmif.h | 1 +
src/gallium/drivers/freedreno/drm/msm_bo.c | 3 +++
src/gallium/drivers/freedreno/freedreno_resource.c | 4 +++-
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git
some instructions can only be scalar on a2xx, lower these only
Signed-off-by: Jonathan Marek
---
.../drivers/freedreno/Makefile.sources| 1 +
src/gallium/drivers/freedreno/a2xx/ir2_nir.c | 3 +
.../freedreno/a2xx/ir2_nir_lower_scalar.c | 174 ++
Not in this patch: emitting the hw binning variant and filling the
"draw_patches". That is part of the ir2 patch.
Signed-off-by: Jonathan Marek
---
src/gallium/drivers/freedreno/a2xx/fd2_draw.c | 51 ++--
src/gallium/drivers/freedreno/a2xx/fd2_emit.c | 8 +-
So I tried to test this with radv and got a bunch of crashes in CTS,
mostly around 3d image support:
#3 0x771a9396 in __assert_fail () from /usr/lib/libc.so.6
#4 0x769da3b4 in
Addr::V2::Gfx9Lib::HwlGetPreferredSurfaceSetting (this=0x57661b30,
pIn=0x7fffd5f0,
From: Nicolai Hähnle
v2:
- use SI_CONTEXT_REG_OFFSET
Reviewed-by: Dave Airlie
---
src/amd/common/sid.h | 3 +++
src/amd/vulkan/radv_cmd_buffer.c | 6 ++
src/amd/vulkan/radv_device.c | 9 -
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git
Jonathan Marek writes:
> some instructions can only be scalar on a2xx, lower these only
Could we have the core ALU scalar lowering take an optional bitmask or
something of ALU ops that need scalar lowering?
signature.asc
Description: PGP signature
On Mon, Nov 19, 2018 at 5:31 PM Timothy Arceri
wrote:
> On 20/11/18 2:46 am, Jason Ekstrand wrote:
> > I also saw a case last week where the induction variable is <=
> > imax(thing, 4) and it'd be nice to unroll those too.
>
> That is an interesting one. It means we could do a simple unroll for
Meson test has a concepts of suites, which allow tests to be grouped
together. This allows for a subtest of tests to be run only (say only
the tests for nir). A test can be added to more than one suite, but for
the most part I've only added a test to a single suite, though I've
added a compiler
Use L3 configuration specified in h/w specification.
V2: Drop configs which do under allocation of l3 cache.
Bump up the comment above table.
Signed-off-by: Anuj Phogat
Cc: Kenneth Graunke
Cc: Francisco Jerez
---
src/intel/common/gen_l3_config.c | 12 ++--
1 file changed, 6
On 20/11/18 2:46 am, Jason Ekstrand wrote:
I also saw a case last week where the induction variable is <=
imax(thing, 4) and it'd be nice to unroll those too.
That is an interesting one. It means we could do a simple unroll for the
first 4 iterations i.e no if statements required, which is a
Dropping this patch.
On Tue, Nov 13, 2018 at 2:34 PM Anuj Phogat wrote:
>
> Config#6 recommended by h/w specification causes multiple piglit
> regressions. Use config#9 instead which works well. Setting a weight
> here so that we get the desired config.
>
> Signed-off-by: Anuj Phogat
> Cc:
One thing I always go to the autoconfig webpage for is to copy and paste
the line for a 32bit cross-compiled mesa build.
It would be good if someone could document the method for cross
compiling on the meson page before we remove autotools.
[1] https://www.mesa3d.org/autoconf.html
On
On Mon, Nov 19, 2018 at 7:15 PM Bas Nieuwenhuizen
wrote:
> So I tried to test this with radv and got a bunch of crashes in CTS,
> mostly around 3d image support:
>
> #3 0x771a9396 in __assert_fail () from /usr/lib/libc.so.6
> #4 0x769da3b4 in
>
Adam Jackson writes:
> On Tue, 2018-10-30 at 16:38 -0700, Eric Anholt wrote:
>> Eric Anholt writes:
>>
>> > The CTS requires a 565-no-depth-no-stencil config for ES 3.0, but at depth
>> > 24 of X11 we wouldn't do so. We can satisfy that bad requirement using a
>> > pbuffer-only visual with
Hi Brian,
On Sunday, 18 November 2018 20:54:50 CET Brian Paul wrote:
> The series looks great. Just a few minor things below.
>
> Reviewed-by: Brian Paul
Thank you!
For reference, the requested changes in the following mail.
I have also used GLubyte for Patch #10 then.
best
Mathias
I'd like to keep ARB_texture_float enabled on drivers that don't support
linear interpolation. ARB_texture_float is required by DX9, which doesn't
require linear interpolation. If you pushed this, you would break DX9 games
for r300, which is de-facto reference DX9 hardware.
Marek
On Mon, Nov 19,
From: Marek Olšák
---
.../drivers/radeonsi/si_shader_tgsi_mem.c | 29 +++
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
index 979e47d3cc4..6decedc4cce
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader_nir.c | 36 +---
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 87ca0161b45..e7ba282b075 100644
---
From: Marek Olšák
---
.../drivers/radeonsi/si_shader_tgsi_mem.c | 45 ---
src/gallium/drivers/radeonsi/si_state.c | 7 +--
2 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
From: Marek Olšák
---
.../drivers/radeonsi/si_shader_tgsi_mem.c | 49 ++-
1 file changed, 37 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
index 2ba3f251ff8..81df73ea9b1
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
index 81df73ea9b1..979e47d3cc4 100644
From: Marek Olšák
---
src/gallium/auxiliary/tgsi/tgsi_scan.c | 28 --
src/gallium/auxiliary/tgsi/tgsi_scan.h | 7 +++
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
From: Mathias Fröhlich
Factor out struct gl_vertex_format from array attributes.
The data type is supposed to describe the type of a vertex
element. At this current stage the data type is only used
with the VAO, but actually is useful in various other places.
Due to the bitfields being used,
From: Mathias Fröhlich
With the current VAO layout we do not need to make these
fields a bitfield. We get a tight struct layout with this change
for VAO attributes.
v2: Change unsigned char -> GLubyte.
Reviewed-by: Brian Paul
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/mtypes.h | 4
On Tue, Nov 20, 2018 at 12:08 AM Dave Airlie wrote:
> On Tue, 20 Nov 2018 at 14:42, Marek Olšák wrote:
> >
> > On Mon, Nov 19, 2018 at 7:15 PM Bas Nieuwenhuizen <
> b...@basnieuwenhuizen.nl> wrote:
> >>
> >> So I tried to test this with radv and got a bunch of crashes in CTS,
> >> mostly around
On Tue, Nov 20, 2018 at 12:08 AM Dave Airlie wrote:
> On Tue, 20 Nov 2018 at 14:42, Marek Olšák wrote:
> >
> > On Mon, Nov 19, 2018 at 7:15 PM Bas Nieuwenhuizen <
> b...@basnieuwenhuizen.nl> wrote:
> >>
> >> So I tried to test this with radv and got a bunch of crashes in CTS,
> >> mostly around
On Tue, 20 Nov 2018 at 14:42, Marek Olšák wrote:
>
> On Mon, Nov 19, 2018 at 7:15 PM Bas Nieuwenhuizen
> wrote:
>>
>> So I tried to test this with radv and got a bunch of crashes in CTS,
>> mostly around 3d image support:
>>
>> #3 0x771a9396 in __assert_fail () from /usr/lib/libc.so.6
On Mon, 2018-11-19 at 11:13 -0500, Ilia Mirkin wrote:
> On Mon, Nov 19, 2018 at 10:40 AM Erik Faye-Lund
> wrote:
> > On Mon, 2018-11-19 at 10:02 -0500, Ilia Mirkin wrote:
> > > Unfortunately this will drop GL 3.0 from Adreno A3xx. I think
> > > we'd
> > > rather fake linear interpolation with F32
On Mon, Nov 19, 2018 at 11:30 AM Erik Faye-Lund
wrote:
>
> On Mon, 2018-11-19 at 11:13 -0500, Ilia Mirkin wrote:
> > On Mon, Nov 19, 2018 at 10:40 AM Erik Faye-Lund
> > wrote:
> > > On Mon, 2018-11-19 at 10:02 -0500, Ilia Mirkin wrote:
> > > > Unfortunately this will drop GL 3.0 from Adreno
On 11/16/18 10:30 PM, Bas Nieuwenhuizen wrote:
On Fri, Nov 16, 2018 at 9:34 AM Samuel Pitoiset
wrote:
On 11/12/18 10:51 PM, Bas Nieuwenhuizen wrote:
These force the index to be used in the instruction so we don't need the
workaround.
Totals:
SGPRS: 1321642 -> 1321802 (0.01 %)
VGPRS:
On GPUs gen < 8 that don't support ETC2 sampling/rendering we now fake
the support using 2 mipmap trees: one (the main) that stores the
compressed data for the Get* functions to work and one (the shadow) that
stores the same data decompressed for the render/sampling to work.
Added the
GPUs Gen < 8 cannot render ETC2 formats. So far, they converted the
compressed EAC/ETC2 images to non-compressed RGB format images that they
can render. When GetCompressed* functions were called, the pixels were
returned in the RGB format and not the compressed format as expected.
Trying to fix
Renamed the r8stencil_mt and r8stencil_needs_update to shadow_mt and
shadow_needs_update respectively to allow reusing the shadow_mt as a
generic purpose secondary mipmap tree.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 8
src/mesa/drivers/dri/i965/intel_mipmap_tree.c|
The assertions that the GL_MAP_WRITE_BIT and GL_MAP_INVALIDATE_RANGE_BIT
in intel_miptree_map_etc should be removed since they will fail when the
ETC miptree is mapped for reading.
Fixes: KHR-GL45.direct_state_access.textures_compressed_subimage crash
on Gen 7 GPUs.
---
Intel Gen7 GPUs don't have native support for ETC2 formats. We store the
ETC2 images as RGBA in order to render them. This is a problem for
GetCompressed* functions that should return compressed pixel values but
return instead RGBA.
With these patches, we store the compressed image data in the
CopyImageSubData couldn't work for the first draw call because
intel_update_decompressed_shadow was called during the rendering. Moved
the intel_update_decompressed_shadow in brw_predraw_resolve_inputs to
fix this problem.
---
src/mesa/drivers/dri/i965/brw_draw.c | 3 +++
1 file changed, 3
Extended the intel_update_decompress_shadow to update all the mipmap
tree levels so that we can display and run Get functions on mipmaps.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 48 +++
1 file changed, 29 insertions(+), 19 deletions(-)
diff --git
Modified the calculation of the number of slices in the
intel_update_decompressed_shadow function to take the array length into
account to support arrays.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
OES_copy_image extension was disabled on Gen7 due to the lack of support
for ETC2 images. Enabled it back.
---
src/mesa/drivers/dri/i965/intel_extensions.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
Hello,
I tried to compile latest mesa master this morning but faced with a
compilation error:
intel_fbo.c: In function ‘intel_validate_framebuffer’:
intel_fbo.c:696:25: error: ‘GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS’
undeclared (first use in this function); did you mean
This only implements the "primary_device" part. This allows EGL to work without
relying on wl_drm anymore.
---
This simple patch implements version 4, which is still in review on
wayland-devel [1].
[1]: https://patchwork.freedesktop.org/series/52370/
src/egl/drivers/dri2/platform_wayland.c |
I was about to write about this too. I think the patch is not
correct for a couple of reasons:
1. GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS is not defined for OpenGL,
only for GL ES. The GL definition has the _EXT suffix and is included
with a specific extension, so I don't think we can use it like
Am Montag, den 19.11.2018, 10:21 +0100 schrieb Iago Toral:
> I was about to write about this too. I think the patch is not
> correct for a couple of reasons:
>
> 1. GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS is not defined for OpenGL,
> only for GL ES. The GL definition has the _EXT suffix and is
On Mon, 2018-11-19 at 10:21 +0100, Iago Toral wrote:
> I was about to write about this too. I think the patch is not
> correct for a couple of reasons:
>
> 1. GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS is not defined for OpenGL,
> only for GL ES. The GL definition has the _EXT suffix and is included
>
Am Montag, den 19.11.2018, 10:26 +0100 schrieb Iago Toral:
> On Mon, 2018-11-19 at 10:21 +0100, Iago Toral wrote:
> > I was about to write about this too. I think the patch is not
> > correct for a couple of reasons:
> >
> > 1. GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS is not defined for OpenGL,
> >
FRAMEBUFFER_INCOMPLETE_DIMENSIONS is not supported for GLES 3.0 and later and
not defined for Desktop OpenGL. Instead use FRAMEBUFFER_UNSUPPORTED like it
was done before.
Thanks to Iago Toral and Andrey Simiklit for pointing out the problem and the
details.
Fixes:
Fixes dEQP-VK.spirv_assembly.type.scalar.i16.*
Fixes: 1f29f4db1e ("nir/builder: Assert that intN_t immediates fit")
Signed-off-by: Samuel Pitoiset
---
src/compiler/nir/nir_builder.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_builder.h
From: Gert Wollny
The structure qdws is not allocated at this point, nor is the
file descriptor set to it's member. Use the fd directly instead.
Fixes: d1a1c21e7621b5177febf191fcd3d3b8ef69dc96
virgl: native fence fd support
Signed-off-by: Gert Wollny
---
Hey Gert,
Nice catch!
Reviewed-by: Robert Foss
On 2018-11-19 10:56, Gert Wollny wrote:
From: Gert Wollny
The structure qdws is not allocated at this point, nor is the
file descriptor set to it's member. Use the fd directly instead.
Fixes: d1a1c21e7621b5177febf191fcd3d3b8ef69dc96
Thanks!
Reviewed-by: Iago Toral Quiroga
On Mon, 2018-11-19 at 10:36 +0100, Gert Wollny wrote:
> FRAMEBUFFER_INCOMPLETE_DIMENSIONS is not supported for GLES 3.0 and
> later and
> not defined for Desktop OpenGL. Instead use FRAMEBUFFER_UNSUPPORTED
> like it
> was done before.
>
> Thanks to
Am Montag, den 19.11.2018, 11:00 +0100 schrieb Iago Toral:
> Thanks!
and pushed, thank you too.
>
> Reviewed-by: Iago Toral Quiroga
>
> On Mon, 2018-11-19 at 10:36 +0100, Gert Wollny wrote:
> > FRAMEBUFFER_INCOMPLETE_DIMENSIONS is not supported for GLES 3.0 and
> > later and
> > not
On Thu, Nov 15, 2018 at 10:51 AM Samuel Pitoiset
wrote:
>
> This has been initially added for a Sascha demo (ie. deferredshadows),
> but as far I can tell this seems to no longer be needed.
>
> No CTS changes on GFX9 and I didn't find a game that is affected.
>
> Signed-off-by: Samuel Pitoiset
>
On 19/11/18 5:18 pm, Timothy Arceri wrote> This series add support for
partial loop unrolling for loops with an
unknown trip count. The new partial_unroll function allows the caller
to specifiy how may times the loop should be unrolled and then the
loop is inserted in the innermost continue
On 11/19/18 11:56 AM, Bas Nieuwenhuizen wrote:
On Thu, Nov 15, 2018 at 10:51 AM Samuel Pitoiset
wrote:
This has been initially added for a Sascha demo (ie. deferredshadows),
but as far I can tell this seems to no longer be needed.
No CTS changes on GFX9 and I didn't find a game that is
On Mon, Nov 19, 2018 at 12:21 PM Samuel Pitoiset
wrote:
>
>
>
> On 11/19/18 11:56 AM, Bas Nieuwenhuizen wrote:
> > On Thu, Nov 15, 2018 at 10:51 AM Samuel Pitoiset
> > wrote:
> >>
> >> This has been initially added for a Sascha demo (ie. deferredshadows),
> >> but as far I can tell this seems to
This will cause the assert to pass when it shouldn't in some cases
with a 32-bit bitsize, and seems like a hack since it's subverting the
point of the assert, which is guarantee that we won't lose any
information by truncating the source. It would be better to fix the
caller that's hitting the
Floating-point depth buffers are only supported on OpenGL 3.0, OpenGL ES
3.0, or if ARB_depth_buffer_float is supported. Because we checked a
driver capability rather than using an extension-check helper, we ended
up incorrectly allowing this on OpenGL ES 1.x and 2.x.
Since this logic is
ctx->Extensions.KHR_texture_compression_astc_ldr is set regardless of
the API that's used, so checking for those direcly will always enable
extensions when they are supported by the driver.
But there's no extension enabling ASTC for OpenGL ES 1.x, so we
shouldn't allow those enums there.
This makes the logic a little bit easier to follow; this is *either*
about ES2 compatibility *or* about gles. GL_RGB565 was added already in
OpenGL ES 1.0.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/glformats.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This makes the logic a little bit easier to follow, and reduce a bit of
repetition.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/context.h | 6 ++
src/mesa/main/glformats.c | 27 +++
2 files changed, 17 insertions(+), 16 deletions(-)
diff --git
ARB_texture_rgb10_a2ui isn't supported on OpenGL ES, we shouldn't expose
it there even if the driver supports it.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/context.h | 6 ++
src/mesa/main/glformats.c | 12 ++--
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git
_mesa_has_FOO_bar() knows about the APIs these extensions should be
supported under, so let's use that to simplify these checks a bit.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/glformats.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git
Using the _mesa_has_FOO_bar helpers is generally more safe and should
generally be prefered over checking driver-caps like this code did,
because the _mesa_has_FOO_bar helpers also verify the API type and
version.
This shouldn't have any practical effect here, as this function only
gets called
All other _mesa_has_foo functions return bool rather than GLboolean, so
let's follow that style here as well.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/context.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
index
There's no extension enabling S3TC formats on OpenGL ES 1.x, so we
shouldn't allow these even if the driver can support it. So let's check
for EXT_texture_compression_s3tc instead of ANGLE_texture_compression_dxt,
which is supported on all other OpenGL variations.
We also need to use
_mesa_es3_error_check_format_and_type isn't specific to OpenGL ES 3.x,
it applies to all versions of OpenGL ES. So let's rename it to reflect
this.
While we're at it, let's also rename a helper function it uses similarly.
As the helper is static, we can also remove the namespacing-prefix from
the
Here's a lengthy patch-series that aims to fix a few simple bugs, where
invalid enums for texture formats were allowed when they shouldn't be.
In general, this is a pattern of checking ctx->Extensions.FOO_bar
instead of _mesa_has_FOO_bar(ctx). The difference is that the former is
really just a
S3_s3tc is the extension that enables this functionality on desktop, so
let's check for that one. The _mesa_has_S3_s3tc() helper already
verifies the API according to the extension-table.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/glformats.c | 8 +++-
1 file changed, 3 insertions(+),
EXT_packed_float isn't supported on OpenGL ES, we shouldn't allow
these enums there, before OpenGL ES 3.0 which also introduce support
for these enums.
Since this check is repeated a lot, let's make a helper for this.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/context.h | 6 ++
ctx->Extensions.ARB_depth_texture is set regardless of the API that's
used, so checking for those direcly will always allow the enums from
this extensions when they are supported by the driver.
So let's instead check for both ARB_depth_texture and OES_depth_texture,
so we support depth textures
ctx->Extensions.ARB_texture_stencil8 is set regardless of the API
that's used, so checking for those direcly will always allow the
enums from this extensions when they are supported by the driver.
So let's instead check for both ARB_texture_stencil8 and
OES_texture_stencil8, so we support depth
Integer textures shouldn't be implicitly exposed on OpenGL ES 1.x and
2.x, but because the code checked against a driver-capability rather
than using an extension-check helper, we ended up accidentally allowing
these enums on older versions when the driver supports it.
Signed-off-by: Erik
This should be equalent of what we did before.
Signed-off-by: Erik Faye-Lund
---
src/mesa/state_tracker/st_extensions.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index
This extension requies OpenGL, and shouldn't be available on OpenGL ES.
So let's not allow the enums from it either.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/glformats.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/glformats.c
On OpenGL ES 2.0, there's separate extensions adding support for
half-float and float textures. So we need to validate the enums
separately as well.
This also prevents these enums from incorrectly being allowed on
OpenGL ES 1.x, where there's no extension that enables this in the
first place.
ctx->Extensions.EXT_texture_sRGB_R8 is set regardless of the API
that's used, so checking for those direcly will always allow the
enums from this extensions when they are supported by the driver.
There's no extension adding support for this on OpenGL ES before
version 3.0, so let's tighten the
ctx->Extensions.EXT_texture_sRGB is set regardless of the API that's
used, so checking for those direcly will always allow the enums from
this extensions when they are supported by the driver.
There's no extension adding support for this on OpenGL ES before
version 3.0, so let's tighten the
ctx->Extensions.EXT_texture_snorm is set regardless of the API
that's used, so checking for those direcly will always allow the
enums from this extensions when they are supported by the driver.
There's no extension adding support for this on OpenGL ES before
version 3.0, so let's tighten the
There's nothing in the ARB_texture_float specification that limits
filterability for floating-point textures, so we need to ensure that
this is required to enable this extension. Luckily, we have just the
right bits ready.
Signed-off-by: Erik Faye-Lund
---
src/mesa/state_tracker/st_extensions.c
OpenGL ES 3.0 require this functionality, so we should also test for it
to avoid incorrectly exposing a too high GLES version.
On desktop, this has been required since all the way back in OpenGL 1.2
anyway.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/version.c | 3 ++-
1 file changed, 2
The OpenGL ES 3.0 specification, table 3.13 lists half-float textures as
filterable, but not float textures. So we shouldn't depend on
ARB_float_texture, which requires full filtering support for both.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/version.c | 4 +++-
1 file changed, 3
ctx->Extensions.EXT_texture_shared_exponent is set regardless of the
API that's used, so checking for those direcly will always allow the
enums from this extensions when they are supported by the driver.
We also need to make sure this is enabled on OpenGL ES 3. Because the
check is repeated,
sRGB textures is a requirement for OpenGL ES 3.0, so let's make sure
we don't incorrectly enable a too high version.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/version.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index
ctx->Extensions.EXT_texture_type_2_10_10_10_REV is set regardless of
the API that's used, so checking for those direcly will always enable
extensions when they are supported by the driver.
There's no corresponding extension for OpenGL ES 1.x/2.0, so we
shouldn't allow these enums there.
ctx->Extensions.OES_texture_float is set regardless of the API
that's used, so checking for those direcly will always allow the
enums from this extensions when they are supported by the driver.
There's no extension enabling floating-point textures for OpenGL
ES 1.x, so we shouldn't allow those
ctx->Extensions.ARB_ES3_compatibility is set regardless of the API
that's used, so checking for those direcly will always enable
extensions when they are supported by the driver.
But there's no extension enabling ETC2 for OpenGL ES 1.x, so we
shouldn't allow those enums there.
Signed-off-by:
EXT_packed_float isn't supported on OpenGL ES, we shouldn't allow
these enums there, before OpenGL ES 3.0 which also introduce support
for these enums.
Signed-off-by: Erik Faye-Lund
---
src/mesa/main/context.h | 6 ++
src/mesa/main/glformats.c | 6 +++---
2 files changed, 9 insertions(+),
On 11/19/18 12:25 PM, Bas Nieuwenhuizen wrote:
On Mon, Nov 19, 2018 at 12:21 PM Samuel Pitoiset
wrote:
On 11/19/18 11:56 AM, Bas Nieuwenhuizen wrote:
On Thu, Nov 15, 2018 at 10:51 AM Samuel Pitoiset
wrote:
This has been initially added for a Sascha demo (ie. deferredshadows),
but as
From: Sergii Romantsov
Xcb-dri3 is installed into custom directory.
Installing of Vulkan on Ubuntu 16.04 fails during relinking.
Potential reason: seems during relinking a path to the custom
dri3-path is missed: glx.la depends on libloader_dri3_helper.la
which depends on XCB_DRI3_LIBS.
Hey Dave,
Thanks for catching this, pushed!
On 2018-11-19 06:47, Dave Airlie wrote:
From: Dave Airlie
The in_fence_fd needs to be initialised to -1.
Fixes: d1a1c21e7 (virgl: native fence fd support)
---
src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c | 1 +
1 file changed, 1
With my limited knowledge of the parts up till now, this is
Reviewed-by: Bas Nieuwenhuizen
with the caveat that this might very well break the Android build.
Have anyone to look at that or do I need to take a stab?
On Mon, Nov 12, 2018 at 4:51 PM Rob Clark wrote:
>
> Moves drm and the ir3
Unfortunately this will drop GL 3.0 from Adreno A3xx. I think we'd
rather fake linear interpolation with F32 textures which are never
used than lose GL 3.0 there...
On Mon, Nov 19, 2018 at 7:16 AM Erik Faye-Lund
wrote:
>
> There's nothing in the ARB_texture_float specification that limits
>
On Thu, 2018-10-11 at 16:36 +0100, Eric Engestrom wrote:
> Those empty variables in the !wayland case are useless and running that
> meson.build with them breaks the build:
>
> [287/850] Generating wayland-drm-client-protocol.h with a custom command.
> FAILED:
On Fri, 2018-11-09 at 13:28 -0800, Dylan Baker wrote:
> meson does this for you with it's warn levels, so we don't need to set
> it ourselves.
>
> Fixes: d1992255bb29054fa51763376d125183a9f602f3
>("meson: Add build Intel "anv" vulkan driver")
Hi.
I've cherry-picked this commit for next
Reviewed-by: Roland Scheidegger
From: mesa-dev on behalf of Gert
Wollny
Sent: Friday, November 16, 2018 6:06:15 PM
To: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] r600: clean up the GS ring buffers when the
context is destroyed
I
Our compile already splits UBO loads into scalars and the untyped
surface read messages we use for SSBO reads and writes only require
dword alignment.
---
src/intel/vulkan/anv_device.c | 7 +++
src/intel/vulkan/anv_extensions.py | 1 +
2 files changed, 8 insertions(+)
diff --git
---
include/vulkan/vulkan_core.h | 35 ---
src/vulkan/registry/vk.xml | 84 +---
2 files changed, 98 insertions(+), 21 deletions(-)
diff --git a/include/vulkan/vulkan_core.h b/include/vulkan/vulkan_core.h
index 4cd8ed51dcd..35c06649aa5 100644
---
1 - 100 of 143 matches
Mail list logo
