Alyssa Rosenzweig writes:
> This patch adds an initial stub for the Gallium driver, containing
> simple screen functions and the majority of the driver headers but no
> actual functionality. It further adds the winsys glue for linking in
> this stub driver via kmsro on Rockchip/Amlogic boards.
Ernestas Kulik writes:
> Reported by Coverity: in the case where there exist hardware and
> non-hardware queries, the code does not jump to err_free_query and leaks
> the query.
>
> CID: 1430194
> Signed-off-by: Ernestas Kulik
I just found these deep in my inbox, and pushed them.
Emil Velikov writes:
> From: Emil Velikov
>
> Earlier commit addressed 7 of the 8 instances available.
>
> Cc: Carsten Haitzler (Rasterman)
> Cc: Eric Anholt
> Fixes: 300d3ae8b14 ("vc4: Declare the cpu pointers as being modified in NEON
> asm.")
> Signe
Rich Felker writes:
> On Tue, Jan 29, 2019 at 08:29:32AM +0100, Patrick Steinhardt wrote:
>> On Mon, Jan 28, 2019 at 02:09:18PM -0800, Dylan Baker wrote:
>> > Quoting Adam Jackson (2019-01-28 09:00:13)
>> > > On Sat, 2019-01-26 at 13:56 +0100, Patrick Steinhardt wrote:
>> > >
>> > > >
Marek Olšák writes:
> Hi,
>
> People don't prefix merge request names with the component they are
> changing, so unrelated people have to open merge requests they don't really
> want to look at.
>
> Could you start adding the component prefix like we do for commits?
Not sure if you've noticed,
Eric Anholt writes:
> [ Unknown signature status ]
> Rob Herring writes:
>
>> If we can't find a driver matching by name, then use the kmsro driver.
>> This removes the need for needing a driver descriptor for every possible
>> KMS driver.
>>
>> Signed-off
Rob Herring writes:
> If we can't find a driver matching by name, then use the kmsro driver.
> This removes the need for needing a driver descriptor for every possible
> KMS driver.
>
> Signed-off-by: Rob Herring
I've pushed patch 1 and 2, and the hx8357d rebase.
signature.asc
Description:
Erik Faye-Lund writes:
> On Fri, 2019-01-25 at 13:41 -0800, Eric Anholt wrote:
>> Nick Kreeger writes:
>>
>> > The OES_texture* extensions for float and half-float are valid when
>> > GLES2 is present w/ the matching
>> > OES_texture_float/O
Nick Kreeger writes:
> The OES_texture* extensions for float and half-float are valid when
> GLES2 is present w/ the matching
> OES_texture_float/OES_texture_half_float extensions. This fix ensures
> that these formats are valid for this configuration.
I don't see OES_texture_float.txt
Rob Clark writes:
> I guess as discovered with
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/47 maybe we
> should wait to turn on merging MRs via web until we have at least some
> basic build-test CI wired up.. the downside is slower 'maintainer'
> response (if I am working on some
Patrick Steinhardt writes:
> The musl libc library does not have any support for the
> "initial-exec" TLS model and is unlikely to ever implement it.
> Thus, TLS support in GLX has been turned off in musl-based
> distributions to work around problems when dlopen'ing drivers.
> While this is
Emil Velikov writes:
> From: Emil Velikov
>
> Earlier commit aimed to remove unneeded function declarations. Namely
> OpenGL entrypoints which are not applicable for OpenGLES*
>
> Although it did not consider the shared glapi which needs all,
> including hidden ones. Resulting in warning/errors
Eduardo Lima Mitev writes:
> ir3 compiler has an integer multiply-add instruction (IMAD_S24)
> that is used for different offset calculations in the backend.
> Since we intend to move some of these calculations to NIR, we need
> a new ALU op that can represent it.
> ---
>
Eduardo Lima Mitev writes:
> This is an internal intrinsic intended to be injected by a
> (freedreno-specific) 'lower_sampler_io' pass that will be introduced
> later in this series; and consumed by ir3_compiler_nir.
>
> The intrinsic will load in SSA values for various constants
> for images
Eric Anholt writes:
> [ Unknown signature status ]
> Rob Herring writes:
>
>> If we can't find a driver matching by name, then use the kmsro driver.
>> This removes the need for needing a driver descriptor for every possible
>> KMS driver.
>>
>> Signed
Rob Herring writes:
> Enable using etnaviv for KMS renderonly. This still needs KMS driver
> name mapping to kmsro to be used automatically.
>
> Signed-off-by: Rob Herring
> diff --git a/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
> b/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
>
Rob Herring writes:
> If we can't find a driver matching by name, then use the kmsro driver.
> This removes the need for needing a driver descriptor for every possible
> KMS driver.
>
> Signed-off-by: Rob Herring
Oh, very nice.
There's some risk here -- for example, vkms (with prime enabled,
Rob Herring writes:
> From: Eric Anholt
>
> The vc4 driver can do prime sharing to many different KMS-only devices,
> such as the various tinydrm drivers for SPI-attached displays. Rename the
> driver away from "pl111" to represent what it will actually support:
> v
urposes, but I can imagine that you may prefer the original patch if
> you ever want to do runtime detection of other features on aarch64.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.
Matt Turner writes:
> NEON (now called ASIMD) is available on all aarch64 CPUs. It seems that
> our code was missing an aarch64 path, leading to util_cpu_caps.has_neon
> always being false on aarch64. I think that means that the NEON tiling
> code in vc4 would not be enabled on aarch64
Timothy Arceri writes:
> On 11/12/18 5:11 pm, Ian Romanick wrote:
>> On 12/10/18 5:52 PM, Timothy Arceri wrote:
>>> On 11/12/18 11:35 am, Ian Romanick wrote:
It seems like someone already sent out patches to implement this, and we
decided to not take it for some reason. Maybe it was
Marek Olšák writes:
> From: "Jiang, Sonny"
>
> and add radeonsi support. This will be used by radeonsi internally.
>
> Signed-off-by: Sonny Jiang
It's still strange to me to be proposing changes to gallium core with no
users of the change.
signature.asc
Description: PGP signature
Daniel Stone writes:
> Hi,
>
> On Tue, 15 Jan 2019 at 12:21, Rob Clark wrote:
>> On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli wrote:
>> > On 1/14/19 2:36 PM, Daniel Stone wrote:
>> > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand
>> > > wrote:
>> > > In other projects, we looked for ways to
Gert Wollny writes:
> 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
Reviewed-by: Eric Anholt
signature.asc
Description
Jason Ekstrand writes:
> On Fri, Jan 11, 2019 at 11:11 AM Kenneth Graunke
> wrote:
>
>> On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote:
>> > On Fri, Jan 11, 2019 at 10:19 AM Kenneth Graunke wrote:
>> > > Those names (nir_var_func_local, nir_var_thread_local, and
>> > >
_scalar_early() calls also allows us to tidy
> up the code a little and merge some loops.
I love the reduction in stage tracking logic.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freede
Eric Anholt writes:
> [ Unknown signature status ]
> Rhys Kidd writes:
>
>> Signed-off-by: Rhys Kidd
>
> Does this actually do anything for us, though? Shouldn't we be hooking
> up our perf_debug() calls to it?
I hooked up perf_debug(), extended the com
Jonathan marek writes:
> Hi,
>
> I didn't verify it, but both r600 and a3xx disable earlyZ when alpha
> test is enabled, so this is almost certainly right.
>
> We don't need to worry about the shader writing Z, it is not part of
> OpenGL ES 2.0 and not implemented by the driver (although the
Jonathan Marek writes:
> Note: the backend must take care that uniform index is now a float
This makes me think that lowering ints to float should be done near the
end of the compile (followed by maybe an algebraic and a dce). As is, I
think nir_lower_io() is going to do bad things to
Jonathan Marek writes:
> Enable earlyZ when alpha test is disabled.
>
> Signed-off-by: Jonathan Marek
> ---
> src/gallium/drivers/freedreno/a2xx/fd2_zsa.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_zsa.c
>
Jason Ekstrand writes:
> I don't know if it was actually in the doc that Jordan wrote up but it's
> courteous of you to send a quick e-mail to the mailing list when you create
> a new MR so that people who aren't regularly trolling the list of MRs are
> at least aware that it exists. Of the 20
Eero Tamminen writes:
> Hi,
>
> On 17.12.2018 8.08, Marek Olšák wrote:
> [...]
>> I think one of the serious usability issues is that environment
>> variables such as CFLAGS, CXXFLAGS, LDFLAGS, and PKG_CONFIG_PATH are not
>> saved by meson for future reconfigures.
>
> I don't know what Meson
Jason Ekstrand writes:
> On Thu, Dec 13, 2018 at 11:07 AM Axel Davy wrote:
>
>> On 13/12/2018 17:57, Mathias Fröhlich wrote:
>> > Hi,
>> > Initially it seemed to me that I am about the only one sticking with
>> mailing lists.
>> > And I personally feel like a too small contributor to really try
Dylan Baker writes:
> [ Unknown signature status ]
> In the autotools discussion I've come to realize that we also need to talk
> about
> the -DDEBUG guard. It seems that there are two different uses, and thus two
> different asks about it:
>
> - Nine (and RadeonSI?) use -DDEBUG to hide generic
Emil Velikov writes:
> On Mon, 10 Dec 2018 at 23:11, Dylan Baker wrote:
>>
>> 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:
>>
eviewed and merged without any discussion on the mesa-dev email
> list.
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
Jason Ekstrand writes:
> Jordan has requested to be made an Owner of the mesa project. As much as I
> may be the guy who pushed to get everything set up, I don't want to do this
> sort of thing on my own. As such, I'm asking for some ACKs. If I can get
> 5 ACKs (at least 2 non-intel) from
Jordan Justen writes:
> Lots of discussion here. :) I hoped to just dip our toes into the
> merge request stream, but the consensus is clearly against my idea. Oh
> well. :)
>
> Here's what I gathered from the discussion:
>
> == Keep email, allow duplicate MR, my idea ==
>
> I don't think anyone
Eric Anholt writes:
> [ Unknown signature status ]
> Eric Engestrom writes:
>
>> Cc: Emil Velikov
>> Cc: Andres Gomez
>> Cc: Juan A. Suarez Romero
>> Cc: Dylan Baker
>> Signed-off-by: Eric Engestrom
>> ---
>> This patch depend
index 383df727a17031214dee..db5b642826e990a5523c 100644
> --- a/src/util/xmlpool/.gitignore
> +++ b/src/util/xmlpool/.gitignore
> @@ -1,8 +1 @@
> -ca
> -de
> -es
> -fr
> -nl
> -sv
> -options.h
> xmlpool.pot
Shouldn't xmlpool.pot also go away?
Other than that
for the surface. This can be different from the
> +* resource nr_samples when the resource is bound using
> +* FramebufferTexture2DMultisampleEXT.
> +*/
> + unsigned nr_samples:8;
Don't you mean:
/**
* Number of samples for the surface. This will be 0 if rendering
* should use the
Ian Romanick writes:
> On 11/29/2018 03:53 PM, Eric Anholt wrote:
>> e<#secure method=pgpmime mode=sign>
>> Erik Faye-Lund writes:
>>
>>> On Wed, 2018-11-28 at 13:43 -0800, Eric Anholt wrote:
>>>> Jordan Justen writes:
>>>>
>
Emil Velikov writes:
> 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.
>
> In Mesa, we have different parts not used by different teams. As such
> we tend to remove stuff when nobody is around
il: I just noticed that this was never reverted from master (and it
> needs to be removed before the 18.3 release)
Acked-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
e<#secure method=pgpmime mode=sign>
Erik Faye-Lund writes:
> On Wed, 2018-11-28 at 13:43 -0800, Eric Anholt wrote:
>> Jordan Justen writes:
>>
>> > This adds the "Developer's Certificate of Origin 1.1" from the
>> > Linux
>> > kernel. I
Eric Engestrom writes:
> On Wednesday, 2018-11-28 13:36:29 -0800, Eric Anholt wrote:
>> Jordan Justen writes:
>>
>> > This documents a mechanism for using GitLab Merge Requests as an
>> > optional, secondary way to get code reviews for patchsets.
>&
Jason Ekstrand writes:
> ---
> src/amd/common/ac_nir_to_llvm.c | 12
> src/compiler/glsl/glsl_to_nir.cpp | 2 +-
> src/compiler/nir/nir_builder.h| 12
> src/compiler/spirv/vtn_glsl450.c | 4 ++--
>
Jordan Justen writes:
> This adds the "Developer's Certificate of Origin 1.1" from the Linux
> kernel. It indicates that by using Signed-off-by you are certifying
> that your patch meets the DCO 1.1 guidelines.
>
> It also changes Signed-off-by from being optional to being required.
>
>
Jordan Justen writes:
> This documents a mechanism for using GitLab Merge Requests as an
> optional, secondary way to get code reviews for patchsets.
>
> We still require all patches to be emailed.
>
> Aside from the potential usage for code review comments, it might also
> help reviewers to
Fixes: 0d17b685b1ff ("gallium/u_tests: add a compute shader test that clears an
image")
---
src/gallium/auxiliary/util/u_tests.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_tests.c
b/src/gallium/auxiliary/util/u_tests.c
index 7c4e98402bef..365d4fa8f171 100644
Ian Romanick writes:
> On 11/26/2018 03:44 PM, Marek Olšák wrote:
>> I don't run meson. I have a script that runs meson. I want to just run
>> the script and I want to it configure or reconfigure.
>>
>> I don't want to add this failure path into my script: "meson ... ||
>> meson --reconfigure
The compiler doesn't know that ny != 0, so x might be uninitialized for
the printf at the end.
---
src/gallium/tests/trivial/compute.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/tests/trivial/compute.c
b/src/gallium/tests/trivial/compute.c
index
Jason Ekstrand writes:
> This way, it's explicit in the opcode name that it's an unordered
> comparison.
> ---
> src/amd/common/ac_nir_to_llvm.c | 2 +-
> src/compiler/glsl/glsl_to_nir.cpp | 4 +-
> src/compiler/nir/nir.h| 2 +-
>
Eric Engestrom writes:
> ... instead of making standard platforms use non-standard functions.
>
> This also reduces the likelihood of someone forgetting to use the
> non-standard function, and reduces the fix to a simple #include.
Thank you so much for doing this!
Reviewed-by:
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
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
Eric Engestrom writes:
> Fixes: d971a4230d54069c996bc "loader: Factor out the common driver
> opening logic from each loader."
> Cc: Eric Anholt
> Signed-off-by: Eric Engestrom
Reviewed-by: Eric Anholt
signature.asc
Desc
Eric Engestrom writes:
> On Thursday, 2018-11-15 15:05:27 -0800, Eric Anholt wrote:
>> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
>> index f32c0cd9885f..8f035b7c7d84 100644
>> --- a/src/gbm/backends/dri/gbm_dri.c
>> +++ b/src
Emil Velikov writes:
> On Thu, 15 Nov 2018 at 23:05, Eric Anholt wrote:
>
>> --- a/src/glx/dri_glx.c
>> +++ b/src/glx/dri_glx.c
>> @@ -199,15 +199,9 @@ clear_driver_config_cache()
>> static char *
>> get_driver_config(const char *driverName)
>&
Previously we would print errors on the console like:
libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize
When we had everything we needed for:
libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize:
DRI2: failed to find EGLDevice
(for a gbm
I need other types from the header now, and "gl.h is big" is not a good
reason to duplicate definitions.
---
src/loader/loader.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/src/loader/loader.c b/src/loader/loader.c
index 461f96aa6a44..041a59212be7 100644
---
Everyone needs to call it, and platform_x11 forgot to.
---
src/egl/drivers/dri2/egl_dri2.c | 2 ++
src/egl/drivers/dri2/platform_android.c | 2 --
src/egl/drivers/dri2/platform_drm.c | 2 --
src/egl/drivers/dri2/platform_surfaceless.c | 2 --
You can tell by "Mesa/configs/default" how old this is. Your build system
really has to provide the DEFAULT_DRIVER_DIR, or other loaders will break.
---
src/glx/dri_common.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index
I copied the code from egl_dri2.c, but the functionality was equivalent
between all the loaders other than their particular environment variables.
---
src/egl/Makefile.am | 3 +-
src/egl/drivers/dri2/egl_dri2.c | 75 +++---
src/egl/meson.build | 3 --
The only thing you do with a dri driver handle is get the extensions
pointer, so just fold it in to simplify the callers.
---
src/glx/dri2_glx.c | 8 +---
src/glx/dri3_glx.c | 8 +---
src/glx/dri_common.c | 20 +++-
src/glx/dri_common.h | 6 ++
src/glx/dri_glx.c
the documentation to refer to both; this involves removing a 'see
> also' for gbm_bo_format, since we can't also use \sa to refer to a
> family of anonymous #defines.
>
> Signed-off-by: Daniel Stone
> Reported-by: Pekka Paalanen
Reviewed-by: Eric Anholt
signatu
Eric Engestrom writes:
> Fixes: 6328536ff28ca26f2ad4e "gbm: Introduce a helper function for
> printing GBM format names."
> Cc: Eric Anholt
> Signed-off-by: Eric Engestrom
r-b.
Oh, how I wish we had merge requests that were gated
Rob Clark writes:
> On Tue, Nov 13, 2018 at 5:25 PM Eric Anholt wrote:
>>
>> Rob Clark writes:
>>
>> > If we can't clear all the buffers with pctx->clear() (say, for example,
>> > because of ColorMask), push the buffers we *can* clear with pctx->c
hments with a quad-draw first
> confuses that logic.
Oh, nice!
Reviewed-by: Eric Anholt
Though it feels pretty silly that the ->clear() caller needs a
clear_with_quad implementation when the ->clear() implementation in the
driver also needs a clear_with_quad implementation f
Emil Velikov writes:
> On Tue, 30 Oct 2018 at 17:49, Eric Anholt wrote:
>>
>> Emil Velikov writes:
>>
>> > Hi Eric,
>> >
>> > On Thu, 25 Oct 2018 at 17:39, Eric Anholt wrote:
>> >>
>> >> This allows vc4 to initialize on
Alyssa Rosenzweig writes:
>> I would love to see this up in src/compiler/nir.
>
> Is there a compelling reason to have it in NIR rather in Gallium, adding
> an extra layer of translation overhead / indirection when coming from
> Gallium blend state? (Mythical future Vulkan support, I guess?)
Alyssa Rosenzweig writes:
> Some mobile GPUs lack fixed-function hardware for blending, instead
> emulating blending via internal shaders. In particular for us, vc4 lacks
> most of the fragment pipeline, implementing blending in the epilogue of
> the fragment shader. Newer Malis supported by
r {
> #ifndef NDEBUG
> unsigned magic; /* for debugging */
> #endif
> @@ -647,6 +655,8 @@ linear_alloc_child(void *parent, unsigned size)
> ptr = (linear_size_chunk *)((char*)[1] + latest->offset);
> ptr->size = size;
> latest->offset += full_size;
&g
gallium/drivers/vc4/vc4_program.c | 3 +-
If you hit src/broadcom/compiler/vir.c as well, the series is:
Reviewed-by: Eric Anholt
Switching vc4/v3d stuff over to variables has been going well and
showing wins -- I think we should probably finish that work and then
simplify these paths by mov
-> 0 (0.00 %)
> Scratch size: 0 -> 0 (0.00 %) dwords per thread
> Code Size: 3618596 -> 3573852 (-1.24 %) bytes
> LDS: 0 -> 0 (0.00 %) blocks
> Max Waves: 26189 -> 26276 (0.33 %)
> Wait states: 0 -> 0 (0.00 %)
I was thinking I wanted to write this patch.
Timothy Arceri writes:
> This pass moves constant outputs to the consuming shader stage
> where possible.
>
> V2: limit pass to scalars for now
> ---
>
> V2 doesn't change any shader-db/vkpipeline-db results as all 32bit
> varyings that we don't skip are already scalar. V2 just avoids a
>
I want it for the format name debugging code.
---
src/gbm/backends/dri/gbm_dri.c | 16
src/gbm/main/gbm.c | 16
src/gbm/main/gbmint.h | 3 +++
3 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/src/gbm/backends/dri/gbm_dri.c
Previously the debug would be:
libEGL debug: No DRI config supports native format 0x20203852
libEGL debug: No DRI config supports native format 0x38385247
but
libEGL debug: No DRI config supports native format R8
libEGL debug: No DRI config supports native format GR88
is a lot easier to
This requires that the caller make a little (stack) allocation to store
the string.
v2: Use gbm_format_canonicalize (suggested by Daniel)
---
src/gbm/main/gbm.c | 20
src/gbm/main/gbm.h | 6 ++
2 files changed, 26 insertions(+)
diff --git a/src/gbm/main/gbm.c
Timothy Arceri writes:
> On 7/11/18 7:40 pm, Samuel Pitoiset wrote:
>> IIRC, I wrote a pass similar to this one a while ago, but never finished
>> it.
>>
>> I don't really like the helper name though, how about
>> nir_link_immediate_varyings()? or nir_link_constant_varyings()?
>
> Sure. Happy
Timothy Arceri writes:
> On Mon, Nov 5, 2018, at 4:44 PM, Timothy Arceri wrote:
>> On 6/11/18 11:30 am, Eric Anholt wrote:
>> > Timothy Arceri writes:
>> >
>> >> For now I have only enabled this for RADV we can do it
>> >&
Timothy Arceri writes:
> For now I have only enabled this for RADV we can do it
> also for radeonsi also but we need to add a CAP for it.
If we're doing this at link time, why not push the constant value from
the producer into the consumer shader and then cut out the varying
entirely?
"Haehnle, Nicolai" writes:
> On 31.10.18 21:41, Marek Olšák wrote:
>> Instead of saying that, you should say "Mesa should be slower with most
>> apps, so that we don't decrease perf for 2 apps too much", because
>> that's what you are saying. It seems like you have some limited belief
>> that
This requires that the caller make a little (stack) allocation to store
the string.
---
src/gbm/main/gbm.c | 18 ++
src/gbm/main/gbm.h | 6 ++
2 files changed, 24 insertions(+)
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 0bf2922bacdd..174f62ad797f 100644
---
Previously the debug would be:
libEGL debug: No DRI config supports native format 0x20203852
libEGL debug: No DRI config supports native format 0x38385247
but
libEGL debug: No DRI config supports native format R8
libEGL debug: No DRI config supports native format GR88
is a lot easier to
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 whatever other buffers the driver happens to have
> given us.
Anyone? Still con
Emil Velikov writes:
> Hi Eric,
>
> On Thu, 25 Oct 2018 at 17:39, Eric Anholt wrote:
>>
>> This allows vc4 to initialize on the Adafruit PiTFT 3.5" touchscreen with
>> the new tinydrm driver I just submitted. If this series extending the
>> pl111/kmsr
Eric Engestrom writes:
> On Thursday, 2018-10-25 09:39:10 -0700, Eric Anholt wrote:
>> This allows vc4 to initialize on the Adafruit PiTFT 3.5" touchscreen with
>> the new tinydrm driver I just submitted. If this series extending the
>> pl111/kmsro driver is accept
Dylan Baker writes:
> [ Unknown signature status ]
> CC'ing Matt and Emil.
>
> This will make the code non-portable from an SSE capable system to a non-sse
> capable system. That's a pretty old system at this point (Pentium III and
> Athlon
> XP), and I don't personaly care, but it's quite
Ian Romanick writes:
> On 10/25/2018 05:13 AM, Eric Engestrom wrote:
>> On Thursday, 2018-10-25 17:54:16 +1100, Timothy Arceri wrote:
>>> On 25/10/18 7:42 am, Ian Romanick wrote:
On 10/23/2018 04:15 AM, Eric Engestrom wrote:
> Suggested-by: Timothy Arceri
>>>
>>> Um no :P I suggested
This allows vc4 to initialize on the Adafruit PiTFT 3.5" touchscreen with
the new tinydrm driver I just submitted. If this series extending the
pl111/kmsro driver is accepted, then I'll extend kmsro with the other
tinydrm drivers as well.
---
src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c |
The vc4 driver can do prime sharing to many different KMS-only devices,
such as the various tinydrm drivers for SPI-attached displays. Rename the
driver away from "pl111" to represent what it will actually support:
various sorts of KMS displays with the renderonly layer used to attach a
GPU.
---
Eric Engestrom writes:
> Fixes errors thrown by GCC's Undefined Behaviour sanitizer (ubsan) every
> time this macro is used.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedeskt
Eric Anholt writes:
> This will be used on V3D to cut down the size of the VS inputs in the VPM
> (memory area for sharing data between shader stages).
Ping on this one. I'd love to land the series behind it.
signature.asc
Description: PGP sig
Jason Ekstrand writes:
> We have a helper that does exactly what the bany_inequal was doing. It
> emits the same code but is a bit higher level and is designed to operate
> on a bvec4.
Patch 6, 8-10 also r-b. I couldn't make sense of patch 7's optimization
pass beforehand, so I failed to
(nir, NULL);
It seems like you ought to have valid where args here. Other than that,
patch 1-5 are:
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
This will be used on V3D to cut down the size of the VS inputs in the VPM
(memory area for sharing data between shader stages).
---
src/compiler/nir/nir_lower_io_to_scalar.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_lower_io_to_scalar.c
Daniel Stone writes:
> Hi all,
>
> On Fri, 21 Sep 2018 at 20:59, Daniel Stone wrote:
>> On Wed, 29 Aug 2018 at 11:13, Juan A. Suarez Romero
>> wrote:
>> > This is a first part, version 2, of a more complete proposal to use GitLab
>> > CI to
>> > build and test Mesa. This first part just adds
For gallium drivers where you want to do some linking at variant compile
time, you don't have the other producer/consumer shader on hand to modify.
By exposing the inner function, the driver can have the used varyings in
the compiled shader cache key and still do linking.
This is also useful for
Fixes assertion failures when calling nir_remove_unused_varyings() or
nir_remove_unused_io_vars().
---
src/compiler/nir/nir_linking_helpers.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/compiler/nir/nir_linking_helpers.c
b/src/compiler/nir/nir_linking_helpers.c
index
101 - 200 of 5366 matches
Mail list logo
