On Fri, 2016-06-17 at 16:09 +0200, ⚛ wrote:
> Hello. Are you editing those files by hand?
Recently as I've come across tabs I do a quick check to see how many
are in the file, if its not many then I remove them.
I don't think there would be much interests in doing a batch conversion
as this
Hi Christian,
Thanks for the review.
I don't understand the compositor code fully yet. How can I create a
unscaled image with it?
Regards,
Nayan.
On Fri, Jun 17, 2016 at 9:15 PM, Christian König
wrote:
> Really nice work. I now understand where your problem is with
Fixes a regression induced by commit a0674ce5:
When EGL_TEXTURE_FORMAT and EGL_TEXTURE_TARGET were both specified (and
both != EGL_NO_TEXTURE), an error was instantly triggered, before the
other one had even a chance to be checked, which is obviously not the
intended behaviour.
Signed-off-by:
https://bugs.freedesktop.org/show_bug.cgi?id=96410
--- Comment #2 from Timothy Arceri ---
(In reply to gregory.hainaut from comment #1)
> Currently looking at the code of single program flow namely
> _mesa_update_shader_textures_used
>
> The current check fails to detect
On Thu, Jun 16, 2016 at 10:57 AM, Chad Versace
wrote:
> On Thu 16 Jun 2016, Jason Ekstrand wrote:
> > On Thu, Jun 16, 2016 at 10:39 AM, Chad Versace
> > wrote:
> >
> > > On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > > > ---
> > > >
On Thu, Jun 16, 2016 at 10:08 AM, Chad Versace
wrote:
> On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > Otherwise, we end up with a bogus value in the third component. On
> gen6-7
> > where we always use 2D textures, this can cause problems if the
> > SurfaceArray bit is
On Friday, June 17, 2016 5:58:21 PM PDT Ilia Mirkin wrote:
> On Fri, Jun 17, 2016 at 5:48 PM, Emil Velikov
> wrote:
> > On 17 June 2016 at 22:22, Jason Ekstrand wrote:
> >> On Fri, Jun 17, 2016 at 2:09 PM, Emil Velikov
>
Looks like some major rework of this commit is in order; I’ll get on it.
> On Jun 17, 2016, at 3:36 PM, Emil Velikov wrote:
>
> Hi Tim,
>
> Does this commit allows us to have generic generated files or it's
> solely workaround the VPERMD intrinsic argument swap ?
It is necessary to reuse existing BOs when dmabufs are imported. There
are 2 cases that need to be handled. dmabufs can be created/exported and
imported by the same process and can be imported multiple times.
Copying other drivers, add a hash table to track exported BOs so the
BOs get reused.
Cc:
Exported dmabufs can get imported by the same process, but the handle was
not getting added to the hash table on export. Add the handle to the hash
table on export.
Cc: Dave Airlie
Signed-off-by: Rob Herring
---
On Friday, June 17, 2016 1:53:19 PM PDT Jason Ekstrand wrote:
> This pass is similar to propagate_invariance in the GLSL compiler. The
> real "output" of this pass is that any algebraic operations which are
> eventually consumed by an invariant variable get marked as "exact".
>
> Signed-off-by:
On Fri, Jun 17, 2016 at 5:48 PM, Emil Velikov wrote:
> On 17 June 2016 at 22:22, Jason Ekstrand wrote:
>> On Fri, Jun 17, 2016 at 2:09 PM, Emil Velikov
>> wrote:
>>>
>>> On 17 June 2016 at 21:12, Mike Gorchak
On 17 June 2016 at 22:22, Jason Ekstrand wrote:
> On Fri, Jun 17, 2016 at 2:09 PM, Emil Velikov
> wrote:
>>
>> On 17 June 2016 at 21:12, Mike Gorchak wrote:
>> > Please understand me right, we are not talking about
On Friday, June 17, 2016 1:53:18 PM PDT Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
> Cc: "12.0"
> ---
> src/intel/vulkan/gen8_cmd_buffer.c | 9 +
> src/intel/vulkan/genX_cmd_buffer.c | 9 +
> 2 files changed, 18
On Fri, Jun 17, 2016 at 2:09 PM, Emil Velikov
wrote:
> On 17 June 2016 at 21:12, Mike Gorchak wrote:
> > Please understand me right, we are not talking about desktop hardware and
> > libraries, only about embedded in case of GL ES.
> GLES
Quoting Jason Ekstrand (2016-06-17 11:15:54)
>
> On Jun 17, 2016 11:07 AM, "Dylan Baker" wrote:
> >
> > Quoting Ian Romanick (2016-06-16 20:07:14)
> > > This patch is
> > >
> > > Reviewed-by: Ian Romanick
> > >
> > > On 06/16/2016 06:15 PM, Dylan
On 17 June 2016 at 21:12, Mike Gorchak wrote:
> Please understand me right, we are not talking about desktop hardware and
> libraries, only about embedded in case of GL ES.
GLES hasn't been "embedded only" for a while I believe.
> What's common for desktop
> usually
Signed-off-by: Jason Ekstrand
Cc: "12.0"
Cc: Kenneth Graunke
---
src/intel/vulkan/anv_pipeline.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/intel/vulkan/anv_pipeline.c
Signed-off-by: Jason Ekstrand
Cc: "12.0"
Cc: Kenneth Graunke
---
src/intel/vulkan/anv_device.c | 2 +-
src/intel/vulkan/anv_meta_clear.c | 1 +
src/intel/vulkan/anv_pipeline.c| 2 ++
Signed-off-by: Jason Ekstrand
Cc: "12.0"
Cc: Kenneth Graunke
---
src/intel/vulkan/anv_private.h | 1 +
src/intel/vulkan/gen8_cmd_buffer.c | 38 ++
Just setting builder->exact isn't sufficient because that only applies to
instructions that are built with the builder but instructions created
manually and only inserted using the builder are left alone.
Signed-off-by: Jason Ekstrand
Cc: "12.0"
Signed-off-by: Jason Ekstrand
Cc: "12.0"
---
src/intel/vulkan/anv_cmd_buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_cmd_buffer.c
b/src/intel/vulkan/anv_cmd_buffer.c
index
It used to be based on the framebuffer which isn't quite right.
Signed-off-by: Jason Ekstrand
Cc: Chad Versace
Cc: "12.0"
---
src/intel/vulkan/genX_cmd_buffer.c | 10 +-
1 file changed, 5 insertions(+), 5
Signed-off-by: Jason Ekstrand
Cc: "12.0"
Cc: Francisco Jerez
---
src/intel/vulkan/anv_allocator.c | 76
src/intel/vulkan/anv_private.h | 13 +++
2 files changed, 89
While we're here, we also fixup MEDIA_VFE_STATE and rename the field in
3DSTATE_VS on gen6-7.5 to be consistent with the others.
Signed-off-by: Jason Ekstrand
Cc: "12.0"
Cc: Francisco Jerez
---
This solves a race condition where we can end up having different stages
stomp on each other because they're all trying to scratch in the same BO
but they have different views of its layout.
Signed-off-by: Jason Ekstrand
Cc: "12.0"
Cc:
Signed-off-by: Jason Ekstrand
Cc: "12.0"
---
src/intel/vulkan/gen8_cmd_buffer.c | 9 +
src/intel/vulkan/genX_cmd_buffer.c | 9 +
2 files changed, 18 insertions(+)
diff --git a/src/intel/vulkan/gen8_cmd_buffer.c
This pass is similar to propagate_invariance in the GLSL compiler. The
real "output" of this pass is that any algebraic operations which are
eventually consumed by an invariant variable get marked as "exact".
Signed-off-by: Jason Ekstrand
Cc: "12.0"
---
src/intel/vulkan/anv_dump.c| 127 +
src/intel/vulkan/anv_private.h | 10 +++
src/intel/vulkan/genX_cmd_buffer.c | 4 ++
3 files changed, 141 insertions(+)
diff --git a/src/intel/vulkan/anv_dump.c b/src/intel/vulkan/anv_dump.c
index
---
src/intel/vulkan/anv_dump.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/intel/vulkan/anv_dump.c b/src/intel/vulkan/anv_dump.c
index 0fee93c..59a6f2a 100644
--- a/src/intel/vulkan/anv_dump.c
+++ b/src/intel/vulkan/anv_dump.c
@@ -90,6 +90,28 @@
A while ago while debugging some driver errors, I added a basic image
dumping mechanism to dump images to PPM files. This little series improves
things and adds support for dumping the framebuffer at the end of every
renderpass. With these patches, you can dump rendering for a frame as
follows:
---
src/intel/vulkan/anv_dump.c | 224 +++-
1 file changed, 139 insertions(+), 85 deletions(-)
diff --git a/src/intel/vulkan/anv_dump.c b/src/intel/vulkan/anv_dump.c
index ffb892c..0fee93c 100644
--- a/src/intel/vulkan/anv_dump.c
+++
---
src/intel/vulkan/anv_dump.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/intel/vulkan/anv_dump.c b/src/intel/vulkan/anv_dump.c
index 307e501..ffb892c 100644
--- a/src/intel/vulkan/anv_dump.c
+++ b/src/intel/vulkan/anv_dump.c
@@ -36,11 +36,10 @@
---
src/intel/vulkan/anv_dump.c| 10 --
src/intel/vulkan/anv_private.h | 3 ++-
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/intel/vulkan/anv_dump.c b/src/intel/vulkan/anv_dump.c
index 63ad2cd..307e501 100644
--- a/src/intel/vulkan/anv_dump.c
+++
Hi Tim,
Does this commit allows us to have generic generated files or it's
solely workaround the VPERMD intrinsic argument swap ?
On 17 June 2016 at 20:25, Tim Rowley wrote:
> @@ -31,8 +31,8 @@
> #pragma warning(disable: 4800 4146 4244 4267 4355 4996)
> #endif
>
>
On Fri, Jun 17, 2016 at 2:49 PM, Emil Velikov wrote:
> On 17 June 2016 at 20:05, Rob Herring wrote:
>> On Fri, Jun 17, 2016 at 1:45 PM, Emil Velikov
>> wrote:
>>> On 17 June 2016 at 18:45, Rob Herring wrote:
Please understand me right, we are not talking about desktop hardware and
libraries, only about embedded in case of GL ES. What's common for desktop
usually uncommon for embedded and vice versa. We are currently ship
libraries from many silicon vendors: Imagination RGX, Mali, Vivante, nVidia
- all
Good spotting. Whoops, will do that.
-Tim
> On Jun 17, 2016, at 2:59 PM, Emil Velikov wrote:
>
> On 17 June 2016 at 20:25, Tim Rowley wrote:
>
>> create mode 100644 src/gallium/drivers/swr/rasterizer/core/conservativeRast.h
>>
> Please
On 17 June 2016 at 20:25, Tim Rowley wrote:
> create mode 100644 src/gallium/drivers/swr/rasterizer/core/conservativeRast.h
>
Please mention the new file in the CORE_CXX_SOURCES list in
Makefile.sources (alphabetically).
Thanks
Emil
On 17 June 2016 at 20:05, Rob Herring wrote:
> On Fri, Jun 17, 2016 at 1:45 PM, Emil Velikov
> wrote:
>> On 17 June 2016 at 18:45, Rob Herring wrote:
>>> Now that the pipe-loader is reference counting the screen creation, it
>>> is
> On Jun 17, 2016, at 2:25 PM, Emil Velikov wrote:
>
> On 17 June 2016 at 14:06, Chuck Atkins wrote:
>> Using these adjusted flags, I can verify SWR running on Intel SandyBridge,
>> Intel Haswell, and AMD Interlagos.
>>
> Not only building
So we can skip the index gather in PA.
---
src/gallium/drivers/swr/rasterizer/core/state.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/swr/rasterizer/core/state.h
b/src/gallium/drivers/swr/rasterizer/core/state.h
index 29048f1..bfa9929 100644
---
---
src/gallium/drivers/swr/rasterizer/core/api.cpp| 13 +-
src/gallium/drivers/swr/rasterizer/core/clip.h | 4 +-
.../drivers/swr/rasterizer/core/conservativeRast.h | 120 +++
src/gallium/drivers/swr/rasterizer/core/context.h | 2 +
Add early-out if no components are enabled. Add asserts.
---
.../drivers/swr/rasterizer/jitter/fetch_jit.cpp| 27 ++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp
---
src/gallium/drivers/swr/Makefile.am| 2 +
.../drivers/swr/rasterizer/jitter/JitManager.cpp | 33 +---
.../drivers/swr/rasterizer/jitter/JitManager.h | 22 ---
.../drivers/swr/rasterizer/jitter/blend_jit.cpp| 13 ++-
Function static destructors were getting called by exit
handlers before context teardown.
---
src/gallium/drivers/swr/rasterizer/core/api.cpp | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/swr/rasterizer/core/api.cpp
Handle SGV stores separate from the stream fetch code.
Because of this change, there is a potential to jit an extra unused store.
---
.../drivers/swr/rasterizer/jitter/fetch_jit.cpp| 170 +
1 file changed, 36 insertions(+), 134 deletions(-)
diff --git
Only adds the attribute mapping to the jitter; no implementation yet.
---
src/gallium/drivers/swr/rasterizer/core/knobs.h | 2 +-
src/gallium/drivers/swr/rasterizer/core/state.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/swr/rasterizer/core/knobs.h
---
src/gallium/drivers/swr/rasterizer/core/frontend.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/drivers/swr/rasterizer/core/frontend.cpp
b/src/gallium/drivers/swr/rasterizer/core/frontend.cpp
index 6e1bc0e..f86f8fa 100644
---
Was trying to store an extra uninitialized component.
Only affects component packing, which isn't enabled (yet).
---
src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp
Move drawIDs from 64-bit to 32-bit to increase perf.
---
src/gallium/drivers/swr/rasterizer/core/api.cpp| 4 +-
src/gallium/drivers/swr/rasterizer/core/context.h | 6 +--
.../drivers/swr/rasterizer/core/ringbuffer.h | 8 ++--
.../drivers/swr/rasterizer/core/threads.cpp| 54
Never be dependent on "draw 0", instead have a bool that makes the draw
dependent on the previous draw or not dependent at all.
---
src/gallium/drivers/swr/rasterizer/core/api.cpp | 6 +++---
src/gallium/drivers/swr/rasterizer/core/context.h| 6 +++---
---
src/gallium/drivers/swr/rasterizer/common/isa.hpp | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/swr/rasterizer/common/isa.hpp
b/src/gallium/drivers/swr/rasterizer/common/isa.hpp
index ef38179..31ea787 100644
---
Mostly bug fixes and cleanups.
Tim Rowley (14):
swr: [rasterizer common] workaround clang for windows __cpuid() bug
swr: [rasterizer common] fix include for Intel compiler
swr: [rasterizer] add support for building avx512 version
swr: [rasterizer jitter] unitialized component fix in fetch
Currently, most code paths between AVX2 and AVX512 are identical
(see changes to knobs.h).
---
src/gallium/drivers/swr/rasterizer/common/simdintrin.h | 4 ++--
src/gallium/drivers/swr/rasterizer/core/format_types.h | 8
src/gallium/drivers/swr/rasterizer/core/knobs.h | 15
---
src/gallium/drivers/swr/rasterizer/common/os.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/swr/rasterizer/common/os.h
b/src/gallium/drivers/swr/rasterizer/common/os.h
index 370c619..45517f6 100644
---
On 17 June 2016 at 14:06, Chuck Atkins wrote:
> Using these adjusted flags, I can verify SWR running on Intel SandyBridge,
> Intel Haswell, and AMD Interlagos.
>
Not only building but running as well (on AMD hardware) - nice :-) If
any issues arise one could tweak things
Granted you fix patch 28 so that it builds, patches 28 through 31 are
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Jun 17, 2016 at 1:45 PM, Emil Velikov wrote:
> On 17 June 2016 at 18:45, Rob Herring wrote:
>> Now that the pipe-loader is reference counting the screen creation, it
>> is unnecessary to do in it the winsys/driver.
[...]
>> -static unsigned
Acked-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Patch 26 is
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Patches 24 and 25 are
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 17 June 2016 at 19:28, Rob Clark wrote:
> On Fri, Jun 17, 2016 at 2:23 PM, Emil Velikov
> wrote:
>> Hi Rob,
>>
>> On 17 June 2016 at 18:45, Rob Herring wrote:
>>
>>> struct pipe_screen {
>>> + int refcnt;
>> Can you please
Hi Erik,
Thanks for your feedback.
Can you suggest a better subject?
After some thinking, should I cast gl_buffer_index before calling the
function?
Thanks
Francesco
Il 17 giu 2016 12:39, "Erik Faye-Lund" ha scritto:
> Now the subject no longer makes any sense.
>
> On Thu,
Patches 22 and 23 are
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 17 June 2016 at 18:45, Rob Herring wrote:
> Now that the pipe-loader is reference counting the screen creation, it
> is unnecessary to do in it the winsys/driver.
>
> Signed-off-by: Rob Herring
> Cc: "Marek Olšák"
> Cc: Ilia Mirkin
On Fri, Jun 17, 2016 at 2:10 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This yields a small performance improvement in Unigine Heaven.
For the series:
Reviewed-by: Alex Deucher
> ---
>
Reviewed-by: Tim Rowley
> On Jun 17, 2016, at 12:14 PM, Bruce Cherniak wrote:
>
> A pipe pointer in the screen allows for access to current device context
> in flush_frontbuffer and resource_destroy. This wasn't tracking current
> context
On Fri, Jun 17, 2016 at 2:23 PM, Emil Velikov wrote:
> Hi Rob,
>
> On 17 June 2016 at 18:45, Rob Herring wrote:
>
>> struct pipe_screen {
>> + int refcnt;
> Can you please use struct pipe_reference throughout and the respective
> pipe_reference API
Hi Rob,
On 17 June 2016 at 18:45, Rob Herring wrote:
> struct pipe_screen {
> + int refcnt;
Can you please use struct pipe_reference throughout and the respective
pipe_reference API from src/gallium/auxiliary/util/u_inlines.h.
Thank you very much for doing this !
Emil
On Jun 17, 2016 11:07 AM, "Dylan Baker" wrote:
>
> Quoting Ian Romanick (2016-06-16 20:07:14)
> > This patch is
> >
> > Reviewed-by: Ian Romanick
> >
> > On 06/16/2016 06:15 PM, Dylan Baker wrote:
> > > This fixes the following piglit tests:
> > >
On 17 June 2016 at 18:20, Ian Romanick wrote:
> From: Ian Romanick
>
> Khronos recommends that the GLES 3.1 library also be called libGLESv2.
> It also requires that functions be statically linkable from that
> library.
>
> NOTE: Mesa has supported
From: Nicolai Hähnle
This yields a small performance improvement in Unigine Heaven.
---
src/gallium/drivers/radeonsi/si_state.c | 22 +-
src/gallium/drivers/radeonsi/si_state_shaders.c | 10 +++---
2 files changed, 24 insertions(+), 8
From: Nicolai Hähnle
---
src/gallium/drivers/radeonsi/sid.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/sid.h
b/src/gallium/drivers/radeonsi/sid.h
index a6d5c05..1363a44 100644
---
Clearly a good idea to move this into common code, but there is just one
important thing you are missing here.
We intentional export the *_winsys_create() in the created libraries to
have only one global file descriptor for all libraries. See the
following files as well:
Quoting Ian Romanick (2016-06-16 20:07:14)
> This patch is
>
> Reviewed-by: Ian Romanick
>
> On 06/16/2016 06:15 PM, Dylan Baker wrote:
> > This fixes the following piglit tests:
> > spec/arb_enhanced_layouts/preprocessor/disabled-defined-core.*
> >
> > Signed-off-by:
https://bugs.freedesktop.org/show_bug.cgi?id=96410
--- Comment #1 from gregory.hain...@gmail.com ---
Currently looking at the code of single program flow namely
_mesa_update_shader_textures_used
The current check fails to detect wrongly reused sampler in multiple shader
stage. The spec seems to
From: Mathias Fröhlich
Similar to _mesa_update_array_format add an argument to
avoid calling FLUSH_VERTICES in certain cases.
This will be used with the following change.
Signed-off-by: Mathias Fröhlich
---
src/mesa/drivers/common/meta.c |
From: Mathias Fröhlich
Hi,
The first two patches fix a bug in tracking the VAO internal
state. The majority of the changeset makes more use of the
state currently tracked in the VAO and transitions to use
more of the first order information found in the VAO instead
of
From: Mathias Fröhlich
When a vertex buffer object gets deleted, it is unbound
at the VAO. To do this use _mesa_bind_vertex_buffer instead
of plain unreferencing the buffer object. This keeps the VAOs
internal state consistent. In this case it showed up with
From: Mathias Fröhlich
The field is only read for printing today and
there it was probably a leftover.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/mtypes.h | 1 -
src/mesa/main/varray.c | 1 -
From: Mathias Fröhlich
Instead of gl_client_array::Enabled inside a VAO,
directly use the gl_vertex_attrib_array::Enabled value
which is the origin of the above.
Signed-off-by: Mathias Fröhlich
---
src/mesa/vbo/vbo_exec_array.c | 15
From: Mathias Fröhlich
Only a debugging function, but move away from
gl_client_array and use the first order information
from the VAO.
Signed-off-by: Mathias Fröhlich
---
src/mesa/vbo/vbo_exec_array.c | 49
From: Mathias Fröhlich
Only a debugging function, but move away from
gl_client_array and use the first order information
from the VAO. Also make use of gl_vert_attrib_name.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/varray.c | 52
From: Mathias Fröhlich
Only a debugging function, but move away from
gl_client_array and use the first order information
from the VAO. Also make use of gl_vert_attrib_name.
Signed-off-by: Mathias Fröhlich
---
src/mesa/vbo/vbo_exec_array.c |
From: Mathias Fröhlich
Similarily to _mesa_all_varyings_in_vbos walk the VAO
to check if we have an illegal mapped buffer object
instead of walking all gl_client_arrays.
Signed-off-by: Mathias Fröhlich
---
src/mesa/vbo/vbo_exec_array.c | 33
From: Mathias Fröhlich
In vbo_draw_transform_feedback we currently look at
exec->array.inputs to determine if all varying
vertex attributes reside in vbos. But the vbo_bind_arrays
call only happens past the vbo_all_varyings_in_vbos
query. Thus we may work on a stale set
From: Mathias Fröhlich
The way it is used today does not care about the
Enabled flag anymore.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/mtypes.h | 1 -
src/mesa/main/varray.c | 1 -
From: Mathias Fröhlich
Implement the equivalent of vbo_all_varyings_in_vbos for
vertex array objects.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/arrayobj.c | 35 +++
src/mesa/main/arrayobj.h | 4
On Fri, Jun 17, 2016 at 1:45 PM, Rob Herring wrote:
> Some gallium drivers have implemented reference counting of pipe_screen
> to avoid creating multiple screens for a device. Move this into the
> pipe-loader where it can be shared.
>
> Not completely sure, but it should not
Now that the pipe-loader is reference counting the screen creation, it
is unnecessary to do in it the winsys/driver.
Signed-off-by: Rob Herring
Cc: "Marek Olšák"
Cc: Ilia Mirkin
---
src/gallium/drivers/r300/r300_screen.c|
This reverts commit e7a27f70b91e202ad9afc3e67e1080572d4d4a0b.
Cc: Emil Velikov
Cc: Dave Airlie
---
src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Some gallium drivers have implemented reference counting of pipe_screen
to avoid creating multiple screens for a device. Move this into the
pipe-loader where it can be shared.
Not completely sure, but it should not necessary to dup() the fd as
dri2_create_screen does that for us already.
Now that the pipe-loader is reference counting the screen creation, it
is unnecessary to do in it the winsys/driver.
Signed-off-by: Rob Herring
Cc: Rob Clark
---
src/gallium/drivers/freedreno/freedreno_screen.c | 1 -
This reverts commit f87330dbce3f67cb531194f63a5db59685dcbbd3.
Cc: Emil Velikov
Cc: Dave Airlie
---
src/gallium/auxiliary/target-helpers/drm_helper.h | 7 +-
src/gallium/drivers/virgl/virgl_screen.c | 1 -
In preparation to add reference counting of pipe_screen in the pipe-loader,
pipe_loader_release needs to destroy the pipe_screen instead of state
trackers.
Signed-off-by: Rob Herring
Cc: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/pipe_loader.h
Now that the pipe-loader is reference counting the screen creation, it
is unnecessary to do in it the winsys/driver.
Signed-off-by: Rob Herring
Cc: Alexandre Courbot
---
src/gallium/drivers/nouveau/nouveau_screen.h | 2 -
I needed to add screen ref counting to vc4 driver, so rather than yet
another copy of the same fd hashing and ref counting code, I implemented
it in the pipe-loader. AFAICT, the pipe-loader is the only place the
winsys create screen functions are called and seemed to be the best
location to
The device name is only needed for WL_bind_wayland_display so make this clear
by only storing the device name when Wayland support is built.
Signed-off-by: Frank Binns
---
src/egl/drivers/dri2/egl_dri2.c | 5 -
src/egl/drivers/dri2/egl_dri2.h | 2
Up until now, DRI3 was only used for devices that have render nodes, unless
overridden via an environment variable, with it falling back to DRI2 otherwise.
This limitation was there in order to support WL_bind_wayland_display as it
requires client opened device node fds to be authenticated, which
1 - 100 of 138 matches
Mail list logo