Hi,
thanks, Faith, for bringing this discussion up.
I think with Venus we are more interested in using utility libraries on
an as-needed basis. Here, most of the time the Vulkan commands are just
serialized according to the Venus protocol and this is then passed to
the host because usually it
Hello,
On Sun, 2022-11-06 at 11:33 -0800, Rob Clark wrote:
> On Fri, Nov 4, 2022 at 1:42 AM Taylor Viktor
> wrote:
> >
> > Dear Developers:
> >
> > I am referring to this document
> > https://docs.mesa3d.org/drivers/venus.html#vtest to develop vulkan
> > related functions, but every time I
On Wed, 2022-10-05 at 17:21 +0200, Erik Faye-Lund wrote:
> On Wed, 2022-10-05 at 08:20 -0400, Alyssa Rosenzweig wrote:
> > + for not requiring rb/ab tags ...
>
> I think it's time to think about making this change all over Mesa as
> well. We're deeply in bed with GitLab by now, so I don't think
>
Hello,
with virgl we want to use fp16, and thanks to NTT it is possible to
add the relevant information to TGSI, so I'd kindly like to ask whether
someone with a stake in TGSI to review this MR:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16321
Many thanks,
Gert
Dear all,
With virgl we are interested in exploiting performance improvements on
e.g. ARM hardware by using fp16 when the guest application uses it.
virgl uses TSGI (as text string) passed to the host to communicate
shaders from the guest to the host, and with TGSI no such information
is
Hello Guus,
On Wed, 2021-10-20 at 18:20 +0800, Guus Ellenkamp wrote:
> My screen freezes every now and then (once a day before, now more
> often) in an Ubuntu 20.04 system. It started using a TURKS AMD
> graphics adapter and after trying many things I thought the adapter
> might be defective,
Hello Jose,
On Tue, 2021-09-21 at 11:48 +, Jose Fonseca wrote:
> Why doesn't Gilab allow one to merge manually?
>
> See https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12940:
>
> * Marge-bot failed to merge the PR due to 2 flaky tests, completely
> unrelated to the commits in
Am Samstag, den 28.11.2020, 02:46 +0100 schrieb Dieter Nützel:
> [48/179] Compiling C++ object
> src/gallium/drivers/r600/libr600.a.p/sfn_sfn_shader_fragment.cpp.o
> FAILED:
> src/gallium/drivers/r600/libr600.a.p/sfn_sfn_shader_fragment.cpp.o
> ccache c++ -Isrc/gallium/drivers/r600/libr600.a.p
Hi,
has anybody any objection to adding a new cap
PIPE_CAP_NIR_ATOMICS_AS_DEREF, see:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6025/diffs?commit_id=1e8c3032b96a4878f6fee44aaa10ca341da97e1f
Otherwise I'd like to merge this to move forward with r600/nir atomics
support,
many
/-/tree/msclc-d3d12
and we intend to upstream this code by breaking it into independent
MRs shortly.
We hope you're all as excited about this as we are!
Gert Wollny, on behalf of the Microsoft development team (Bill
Kristiansen and Jesse Natalie) and the Collabora development team
(Boris Brezillon
Hello Dieter,
Am Mittwoch, den 12.02.2020, 10:53 +0100 schrieb Gert Wollny:
>
> When I enable radeonsi linking libgallium_dri.so seems to take
> forever, that is so far it is not finished and it is running for
> quite some time (>15 min). I'll get back to you when I get some
&g
si is ~40% smaller and 16-20% faster with PGO (!!!).
>
> Honza and the GCC people (Intel's ICC folks) do GREAT things.
> 'glmark2' numbers are better then 'vkmark'. (Hello, Marek.).
>
> Need some sleep.
>
> See my log, below.
>
> Greetings and GREAT work!
>
> -Di
Am Donnerstag, den 23.01.2020, 20:31 +0100 schrieb Gert Wollny:
> has anybody any objections if I merge the r600/NIR code?
> Without explicitely setting the debug flag it doesn't change a
> thing, but it would be better to continue developing in-tree.
Okay, if nobody objects, I
Dear all,
has anybody any objections if I merge the r600/NIR code?
Without explicitely setting the debug flag it doesn't change a thing,
but it would be better to continue developing in-tree.
Best,
Gert
___
mesa-dev mailing list
Am Donnerstag, den 28.11.2019, 13:22 +1000 schrieb Dave Airlie:
> On Wed, 27 Nov 2019 at 21:08, Gert Wollny
> wrote:
> >
> > Before that I'd like to un-tabbify the whole r600 driver code,
> > because all the other parts of mesa I've been touching use spaces,
> > a
Hello Dave,
I was wondering how much interest you still have in R600? I'm preparing
to start feeding my NIR work as MRs to continue my work in-tree. It is
currently only for Evergreen and still far from feature parity
with TGSI (no tesselation, no images, nor SSBOs), some things regress,
but
Am Freitag, den 11.10.2019, 09:47 -0700 schrieb Dylan Baker:
>
> I prefer this to .
>
> To echo Dave's concern, if we ever decided to have a non-backwards
> compatible API change (say Intel decided that since we don't use
> libdrm_intel anymore we don't want to maintain it and want to drop
> it)
into account *somewhere* otherwise the
> > > whole
> > > thing can't possibly work.
> > >
> > > -ilia
> > >
> > > On Fri, Aug 2, 2019 at 8:11 PM Marek Olšák
> > > wrote:
> > > > IIRC, perspective interpolation is drive
Am Freitag, den 02.08.2019, 15:09 -0400 schrieb Ilia Mirkin:
> On Fri, Aug 2, 2019 at 1:28 PM Gert Wollny > wrote:
> > Am Donnerstag, den 01.08.2019, 07:22 -0400 schrieb Ilia Mirkin:
> > > Hey Gert,
> > >
> > > I'm looking at
> > > h
Am Donnerstag, den 01.08.2019, 07:22 -0400 schrieb Ilia Mirkin:
> Hey Gert,
>
> I'm looking at
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=b048d8bf8f056759d1845a799d4ba2ac84bce30f
> , which attempts to implement depth clamping (rather than clipping)
> with shader tricks.
>
> You're
Am Montag, den 29.07.2019, 11:39 -0400 schrieb Ilia Mirkin:
> Hi Gert,
>
> I just saw you pushed commit
>
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=4ee638cd7826e8a4bed76f51c7b73395a2fcdb
>
> which just returns if rasterizer_discard is set, similar to if the
> render condition doesn't
On So, 2019-05-26 at 21:45 +0200, Bas Nieuwenhuizen wrote:
> r600g does not have a nir compiler,
I'm working on this in an out of tree bruch, but well, I can always re-
introduce the flag when I start to upstream this, so keep it or leave
it.
Ack-by: Gert Wollny
> and radeonsi does n
This fixes the issues I had when running Outast via vigl, thanks
Tested-By: Gert Wollny
On Di, 2019-05-21 at 14:34 -0400, Marek Olšák wrote:
> From: Marek Olšák
>
> Don't update non-buffer images.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id
Hi Marek,
it seems that this patch is causing a few issues [1], any idea what is
going on? Maybe it is best to revert the patch for now?
Best,
Gert
[1] https://bugzilla.freedesktop.org/show_bug.cgi?id=110701
On Fr, 2019-05-10 at 01:19 -0400, Marek Olšák wrote:
> From: Marek Olšák
>
>
ion then it shouldn't be too much (here an EXT
extension for GLES is not superseted by an extension that is only
available for OpenGL).
Best, Gert
>
> Marek
>
> On Wed, May 15, 2019 at 10:39 AM Gert Wollny
> wrote:
> > How about moving these extensions to anothe
How about moving these extensions to another (new) section? I think it
is nice to have a one-stop place to find out what is supported.
Best,
Gert
On Di, 2019-05-14 at 16:07 -0400, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> docs/features.txt | 10 --
> 1 file changed, 10
Hi Roland,
I did some softpipe patches, maybe you could take a look?
Fixing LOD evaluation, cube face selection, and add support for
explicit derivatives:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/702
On top of that (i.e. the MR includes the above)
Softpipe add support for
> > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier <
> > > tournier.e...@gmail.com> wrote:
> > > >
[...]
> > > > A solution would be to inline the
> > > > function in GLSL but I'm scared than the following shader will
> > > > be huge.
From my adventures in R600 Evergreen NIR land I can say
EXT_sRGB_write_control and EXT_texture_sRGB_R8 are now supported
on all drivers that support sRGB.
Signed-off-by: Gert Wollny
CC:
---
docs/relnotes/19.0.0.html | 2 ++
1 file changed, 2 insertions(+)
diff --git a/docs/relnotes/19.0.0.html b/docs/relnotes/19.0.0.html
index 1b4edd7ce76
Hello Eric or Tapani (or anybody else working on the Intel driver),
I wonder whether one of you could give me an R-B for the Intel patch
[1] in this MR [2]. As far as I can see your CI [3] shows only
unrelated changes.
many thanks,
Gert
[1]
Am Donnerstag, den 24.01.2019, 22:25 -0800 schrieb Stéphane Marchesin:
>
> Yes, it's for running virgl on top of GLES. To emulate fp64 in GL on
> the guest side, we need fp64 on the host...
BTW: we could also get it emulated from the guest side. When Elie (in
CC) initially proposed the fp64
Dear all,
I'd like to push this series [1] to enable the extension
EXT_sRGB_write control by the end of this week if there are no
objections.
I ran it trough the intel-ci [2] with only some unrelated unstable
tests.
many thanks for any reviews,
Gert
[1]
Hello Matt,
Am Mittwoch, den 16.01.2019, 10:17 -0800 schrieb Matt Turner:
> any idea how to quell this would be very welcome.
>
> It's required to scalarize fp64 operations before this lowering code
> will work. It looks to me like it's trying to call __fadd64 with a
> dvec4 argument, when the
Hello,
I'm trying to get soft-fp64 working with my experimental r600-nir
backend, and thanks to Dave's contribution it is already tied in,
some instructions are not yet supported by the backend, but when
running the piglits I have already 24 tests passing. However, there are
also 1099 test
Am Freitag, den 11.01.2019, 17:28 -0500 schrieb Ilia Mirkin:
> On Fri, Jan 11, 2019 at 5:12 PM Matt Turner
> wrote:
> >
> [sorry Gert, not sure how to classify you]
>
> I think the vmware team (which largely maintains llvmpipe and svga)
> is probably worth hearing from -- I believe they've
Am Donnerstag, den 03.01.2019, 14:28 +0100 schrieb Gert Wollny:
> Tested it, looks fine,
> Reviewed-By: Gert Wollny
Sorry, that should be
>
> Am Freitag, den 28.12.2018, 16:54 +1000 schrieb Dave Airlie:
> > From: Dave Airlie
> >
> > This stores the rast
Tested it, looks fine,
Reviewed-By: Gert Wollny
Am Freitag, den 28.12.2018, 16:54 +1000 schrieb Dave Airlie:
> From: Dave Airlie
>
> This stores the raster state and calls the correct primconvert
> interface
> using the currently bound raster state.
>
> This fixes pigl
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/58
The extension NV_depth_clamp is written against OpenGL 1.2.1, and since
GLES 2.0 is based on GL 2.0 there is no reason not to enable this
extension also for GLES >= 2.0.
Best,
Gert
___
Looks good to me,
Reviewed-By: Gert Wollny
Am Donnerstag, den 27.12.2018, 16:11 +1000 schrieb Dave Airlie:
> From: Dave Airlie
>
> Older versions of virglrenderer before
> 33da7361aec486290df0aec4ad8dfa8ff6adde2c
> in vtest mode, misrender gears.
>
> Fixes: 9d81cd8e7c
Hello Stuart,
Am Donnerstag, den 20.12.2018, 13:40 +1100 schrieb Stuart Young:
> Gert/Ilia,
>
> Could this be reduced this from an error to a warning, with the
> command-line option suppressing the warning?
>
> Perhaps as well as producing the warning, the build could sleep for
> say 30
Hello all,
With the last (minor) update I moved the series to an MR:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/14
There are only one minor change from the series last posted here
v7: use _mesa_has_EXT_framebuffer_sRGB instead of testing the extension
flag directly.
v6: - rename
Am Mittwoch, den 19.12.2018, 12:19 -0500 schrieb Ilia Mirkin:
> On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny
> wrote:
> >
> > Since Meson will eventually be the only build system deprecate
> > autotools
> > now. It can still be used by invoking configure with the
Hi Ilia,
Am Sonntag, den 16.12.2018, 12:40 -0500 schrieb Ilia Mirkin:
> On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny
> wrote:
> >
> > Since Meson will eventually be the only build system deprecate
> > autotools
> > now. It can still be used by invoking configur
Reviewed-By: Gert Wollny
Am Donnerstag, den 06.12.2018, 15:00 +0100 schrieb Nicolai Hähnle:
> From: Nicolai Hähnle
>
> ---
> src/gallium/drivers/r600/sb/sb_ir.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/r600/sb/sb
Am Freitag, den 14.12.2018, 13:11 +0100 schrieb Gert Wollny:
> Am Freitag, den 14.12.2018, 01:19 -0500 schrieb Ilia Mirkin:
> > I have to say that the user experience for autotools is WAY better
> > than for meson. As a concrete example, I had a meson build. Then I
> >
Since Meson will eventually be the only build system deprecate autotools
now. It can still be used by invoking configure with the flag
--enable-autotools
Signed-off-by: Gert Wollny
---
IMO autotools should be properly deprecated prior it its removal, so here
is a patch to do just that. I
.
framebuffer_srgb_enabled*
pass (with MESA_GLES_VERSION_OVERRIDE=3.2).
Best,
Gert
Am Donnerstag, den 15.11.2018, 13:45 +0100 schrieb Gert Wollny:
> From: Gert Wollny
>
> Dear all,
>
> after the RFC and Ilias comments I reworked the series another
> time.
>
Am Freitag, den 14.12.2018, 12:38 +0100 schrieb Samuel Pitoiset:
>
> On 12/13/18 9:27 PM, Gert Wollny wrote:
> > IMHO allowing MRs is a good thing, so
> > Acked-by: Gert Wollny
> >
>
> Allowing MRs isn't a bad thing. The main problem IMHO is that now we
> ha
Am Freitag, den 14.12.2018, 01:19 -0500 schrieb Ilia Mirkin:
> I have to say that the user experience for autotools is WAY better
> than for meson. As a concrete example, I had a meson build. Then I
> updated meson (0.48.1 to 0.48.2). Now ninja -C foo doesn't work.
> meson
> --reconfigure (which
Am Montag, den 10.12.2018, 15:10 -0800 schrieb Dylan Baker:
> Meson 0.49.0 has been out for a couple of days now, and I'd like to
> make the final call for autotools. My patch is so massive that it's a
> huge pain to send to the list, the latest versions is here:
>
Am Donnerstag, den 13.12.2018, 22:20 +0100 schrieb Erik Faye-Lund:
> On Thu, 2018-11-15 at 13:45 +0100, Gert Wollny wrote:
> > From: Gert Wollny
> >
> > Dear all,
> >
> > after the RFC and Ilias comments I reworked the series another
> > time
IMHO allowing MRs is a good thing, so
Acked-by: Gert Wollny
I've added a little remark below.
Best,
Gert
Am Mittwoch, den 05.12.2018, 15:32 -0800 schrieb Jordan Justen:
> This documents a process for using GitLab Merge Requests as an second
> way to submit code changes for Mesa
This fixes rendering in Supertuxkart, Serious Sam 3, and Shadow Warrior
via virgl for me. So for the series:
Tested-By: Gert Wollny
Am Dienstag, den 11.12.2018, 15:26 +0100 schrieb Erik Faye-Lund:
> Virglrenderer does the wrong thing when given an instance divisor;
> it tries
Am Dienstag, den 04.12.2018, 14:01 -0800 schrieb Matt Turner:
> On Tue, Dec 4, 2018 at 12:48 PM Gert Wollny
> wrote:
> > FWIW, I also don't understand the urge to remove the automake build
> > system files, they account for less then 1% of line count in the
> > sourc
Am Dienstag, den 04.12.2018, 14:47 -0500 schrieb Jan Vesely:
>
> > You can, that's what I've done as well. 0.49 just has a much nicer
> > mechanism (and one that presumably distro packagers can use more
> > easily).
>
> I don't understand why distros are such a big focus. Don't they all
> have
Am Dienstag, den 04.12.2018, 10:35 +0100 schrieb Erik Faye-Lund:
>
> But looking through both virgl and virglrenderer, I can't spot
> anything obviously wrong with the way inputs are being set up...
>
> > May be you can observe the same type of VAO in Serious Sam 3?
>
> I don't have Serious Sam
Hello all,
Am Donnerstag, den 29.11.2018, 17:44 + schrieb Emil Velikov:
> Hi all,
>
> I can see why people may opt to not use or maintain the autotools
> build. Although I would kindly ask that we do not remove it just yet.
I second that, I think the process of removing autotools should be
From: Gert Wollny
vtest doesn't implement the according API and would segfault:
Program received signal SIGSEGV, Segmentation fault.
#0 0x in ?? ()
#1 in virgl_fence_server_sync at
src/gallium/drivers/virgl/virgl_context.c:1049
#2 in st_server_wait_sync
From: Gert Wollny
Avoids:
Conditional jump or move depends on uninitialised value(s)
at 0x9E2B39F: virgl_vtest_winsys_resource_cache_create
(virgl_vtest_winsys.c:379)
by 0x9E2725F: virgl_buffer_create (virgl_buffer.c:169)
by 0x9E246D5: virgl_resource_create (virgl_resource.c:60
Hello Tapani,
since you wrote the original code, could you have a look at this patch?
Many thanks,
Gert
Am Freitag, den 16.11.2018, 19:12 +0100 schrieb Gert Wollny:
> From: Gert Wollny
>
> When a shader program is de-serialized the gl_shader_program passed
> in
> may actu
swizzles for unused components in GL_RED and GL_RG
Signed-off-by: Gert Wollny
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965
: be more specific about FBO completeness errors
Signed-off-by: Gert Wollny
---
src/mesa/drivers/dri/i965/intel_fbo.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
b/src/mesa/drivers/dri/i965/intel_fbo.c
index 7e40d61a47
n) from 12 fps to 26 (Host 68). (All on
r600 - 6870 HD).
Tested-By: Gert Wollny
Am Mittwoch, den 21.11.2018, 20:08 -0800 schrieb Gurchetan Singh:
> We flush everytime the command buffer (16 kB) is full, which is
> quite costly.
>
> This impro
Am Mittwoch, den 21.11.2018, 13:14 + schrieb Emil Velikov:
> From: Emil Velikov
>
> More or less any issue pointed out by the compiler is an error. Make
> sure we flag and bail loudly.
>
> Cc: Eric Engestrom
> Signed-off-by: Emil Velikov
> ---
> Eric, feel free to squash this with your
Am Dienstag, den 20.11.2018, 09:07 -0800 schrieb Dylan Baker:
>
>
> I can't reproduce this in any configuration I can come up with,
> what's your meson configuration line?
I there a way to get the command line from a configured directory? -
because I didn't do it in one go. In fact, I added the
From: Gert Wollny
When moving the CPU tests to src/util the needed bits were no longer pulled
here in when doing debug builds resulting in
g++ -o src/gallium/tests/trivial/quad-tex ...
src/util/libmesa_util.a(u_cpu_detect.c.o): In function `call_once':
../include/c11/threads_posix.h:96
Great!
Tested-By: Gert Wollny
Am Montag, den 19.11.2018, 13:49 -0800 schrieb Dylan Baker:
> 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
Thanks for cleaning up my mess,
Reviewed-By: Gert Wollny
Am Montag, den 19.11.2018, 13:15 +0100 schrieb Erik Faye-Lund:
> 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 ext
Am Montag, den 19.11.2018, 12:18 -0800 schrieb Mark Janes:
> Eric Engestrom writes:
>
> > Patches 1-3 are:
> > Reviewed-by: Eric Engestrom
> >
> > Patch 4 is:
> > Acked-by: Eric Engestrom
>
> For external contributors, patches like this should not be R-B or
> Acked unless they have been
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 G
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
---
src/gallium/winsys/virgl/drm
: ebcde3454552adc6d3fea8af2207aafaba857796
i965: be more specific about FBO completeness errors
Signed-off-by: Gert Wollny
---
src/mesa/drivers/dri/i965/intel_fbo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
b/src/mesa/drivers/dri/i965/intel_fbo.c
index
i965/intel_fbo.c
> > > @@ -693,7 +693,7 @@ intel_validate_framebuffer(struct gl_context
> > > *ctx, struct gl_framebuffer *fb)
> > > d_depth != s_depth ||
> > > depthRb->mt_level != stencilRb->mt_level ||
> > > de
depthRb->mt_layer != stencilRb->mt_layer) {
> > - fbo_incomplete(fb,
> > GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS,
> > + fbo_incomplete(fb,
> > GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS_EXT,
> > "FBO
From: Gert Wollny
With 5d517a streamout info is only attached to the shader for which the
transform feedback is actually recorded, but the driver set the context info
with each state submitted, thereby always using the info data that was
attached to the vertex shader.
Pass the streamout
Am Freitag, den 16.11.2018, 20:04 -0800 schrieb Dylan Baker:
>
> Is there anything else we're missing in meson to be able to drop
> autotools?
One thing that I notes is that it seems to be impossible to run the
test suite for just one subdirectory because the only way to run the
build is from
From: Gert Wollny
When a shader program is de-serialized the gl_shader_program passed in
may actually still hold memory allocations for the transform feedback
varyings. If that is the case, free the varying names and reallocate
the new storage for the names array.
This fixes a memory leak
From: Gert Wollny
Fixes memory leak:
104,104 bytes in 13 blocks are definitely lost in loss record 591 of 591
at 0x4C2FE4D: calloc (vg_replace_malloc.c:711)
by 0x7E155DE: generate_gs_copy_shader (r600_shader.c:2489)
by 0x7E1BD1D: r600_shader_from_tgsi (r600_shader.c:4268)
by 0x7E0E669
I forgot:
Fixes: 1371d65a7fbd695d3516861fe733685569d890d0
r600g: initial support for geometry shaders on evergreen (v2)
Am Freitag, den 16.11.2018, 12:48 +0100 schrieb Gert Wollny:
> From: Gert Wollny
>
> This fixes two memory leaks reported by ASAN:
>
> Direct leak of 2
From: Gert Wollny
This fixes two memory leaks reported by ASAN:
Direct leak of 248 byte(s) in 1 object(s) allocated from:
in malloc (/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/libasan.so+0xdb880)
in r600_alloc_buffer_struct
../../samba/mesa/src/gallium/drivers/r600/r600_buffer_common.c:578
.functional.srgb_texture_decode.skip_decode.sr8.*
dEQP-GLES31.functional.texture.filtering.cube_array.formats.sr8*
Signed-off-by: Gert Wollny
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
src/mesa/drivers/dri/i965/intel_extensions.c| 1 +
2 files changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965
.functional.fbo.completeness.renderable.texture.color0.sr8_ext
fail because it expects GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT (which makes
sense), but I thought when I touch this code, I could as well go through
the hole list.
Thanks for any reviews,
Gert
Gert Wollny (4):
i965: Correct L8_UNORM_SRGB table entry
i965: be more specific
This makes it possible to use a hardware luminance format as RED format.
Signed-off-by: Gert Wollny
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965
The driver was returning GL_FRAMEBUFFER_UNSUPPORTED for all cases of an
incomplete fbo, be a bit more specific about this following the description
of glCheckFramebufferStatus.
This helps to keeps dEQP happy when adding EXT_texture_sRGB_R8 support.
Signed-off-by: Gert Wollny
---
src/mesa
As the name says, the format is an sRGB format.
Signed-off-by: Gert Wollny
---
src/intel/isl/isl_format_layout.csv | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/isl/isl_format_layout.csv
b/src/intel/isl/isl_format_layout.csv
index 0b9421e3f9..a1efa66657 100644
From: Gert Wollny
Use EXT_framebuffer_sRGB to expose EXT_sRGB_write_control on GLES. Remove
the checks for desktion GL in the enable calls, since EXT_framebuffer_sRGB
now also indicates support for switching the linear-sRGB color
space conversion on GLES.
This patch enables and makes pass
From: Gert Wollny
EXT_sRGB is an (incomplete) GLES extension that provides support for sRGB
framebuffer attachments, hence it can be used to check for this support
as an alternative to EXT_framebuffer_sRGB that provides the same
functionality but also sRGB write control support.
However, since
From: Gert Wollny
For GLES sRGB framebuffer attachemnt support is provided in two steps:
(1) sRGB attachments like described in EXT_sRGB (and GLES 3.0) that enable
linear to sRGB color space transformation automatically, and (2) the ability
to switch formats of the render target surface between
From: Gert Wollny
GLES 3.0 does not actually require support for EXT_framebuffer_sRGB, it
only needs support for sRGB attachments to framebuffers and framebuffer
objects as defined in ARB_framebuffer_objects.
v2: Clarify that ARB_framebuffer_objects is needed.
Signed-off-by: Gert Wollny
From: Gert Wollny
All drivers that support EXT_framebuffer_sRGB also support EXT_sRGB, but
in order to keep this commit minimal, and not to break any drivers both
flags are checked.
v2: - Use only EXT_sRGB (Ilia Mirkin)
- Move adding the flag EXT_sRGB to gl_extensions to a separate patch
From: Gert Wollny
Add a new cap that indicates whether the drivers supports
enabling/disabling the conversion from linear space to sRGB
for a framebuffer attachment. In Driver terms that this CAP indicates
whether the driver can switch between a linear and and a sRGB surface
format for draw
From: Gert Wollny
v2: - Use the renamed CAPS
- add assertions to make sure that mesa doesn't try to switch
destination surface formats when it is not supported. (Ilia Mirkin)
Signed-off-by: Gert Wollny
---
src/gallium/drivers/virgl/virgl_context.c | 10 ++
src/gallium
From: Gert Wollny
Signed-off-by: Gert Wollny
---
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index d7e02efb54..ca369e39f2 100644
--- a/src/mesa
From: Gert Wollny
Dear all,
after the RFC and Ilias comments I reworked the series another time.
Changes with respect to the RFC are
- renaming the new CAP
- reordering of the patches that no double checking of
EXT_sRGB and EXT_framebuffer_sRGB is needed.
thanks for reviewing
Hi Kenneth,
unfortunately this patch breaks r600. I tried to dig into it to figure
out where things going wrong but I was not very successful so far.
While the right shader (TES) registers the stream output in the shader
translation also with your patch, querying with GL_QUERY_RESULT just
now
From: Gert Wollny
Signed-off-by: Gert Wollny
---
src/mesa/main/fbobject.c | 2 +-
src/mesa/main/teximage.c | 3 +--
src/mesa/main/version.c | 5 ++---
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index ca3f3f7f76
From: Gert Wollny
Use EXT_framebuffer_sRGB to expose EXT_sRGB_write_control on GLES. Remove
the checks for desktion GL in the enable calls, since EXT_framebuffer_sRGB
now also indicates support for switching the linear-sRGB color
space conversion on GLES.
Thanks to Ilia Mirkin for all
From: Gert Wollny
Signed-off-by: Gert Wollny
---
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index d7e02efb54..ca369e39f2 100644
--- a/src/mesa
From: Gert Wollny
For GLES sRGB framebuffer attachemnt support is provided in two steps:
sRGB attachments like described in EXT_sRGB and GLES 3.0 that enable
linear to sRGB color space transformation automatically, and sRGB write
control that brings GLES on par with EXT_framebuffer_sRGB. Set
From: Gert Wollny
EXT_sRGB is an (incomplete) GLES extension that provides support for sRGB
framebuffer attachments, hence it can be used to check for this support
as an alternative to EXT_framebuffer_sRGB that provies the same
functionality but also sRGB write control support.
All drivers
1 - 100 of 826 matches
Mail list logo
