https://bugs.freedesktop.org/show_bug.cgi?id=109867
Bug 109867 depends on bug 109860, which changed state.
Bug 109860 Summary: vulkan component not working
https://bugs.freedesktop.org/show_bug.cgi?id=109860
What|Removed |Added
https://bugs.freedesktop.org/show_bug.cgi?id=109860
Samuel Pitoiset changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109867
Samuel Pitoiset changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109791
--- Comment #4 from Malik Riaz ---
BHai awaz aa rahi hay meri?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=109860
--- Comment #1 from Malik Riaz ---
BHai awaz aa rahi hay meri?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=109867
Bug ID: 109867
Summary: vulkan component not working
Product: Mesa
Version: 18.3
Hardware: Other
OS: All
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=109860
Ijlal Asif changed:
What|Removed |Added
Blocks||109867
Referenced Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=109860
Bug ID: 109860
Summary: vulkan component not working
Product: Mesa
Version: 18.3
Hardware: Other
OS: All
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=109858
Osama Mumtaz changed:
What|Removed |Added
Alias||musharib.saji...@gmail.com
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=109858
Bug ID: 109858
Summary: Bug report for learning purposes
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: NEW
Severity:
https://bugs.freedesktop.org/show_bug.cgi?id=109791
Tayyab Ali changed:
What|Removed |Added
CC||tayyabali3...@gmail.com
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=44239
Salik changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |sujuvi...@techgroup.top
|org
https://bugs.freedesktop.org/show_bug.cgi?id=109851
Kamal Hasan changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=44239
Salik changed:
What|Removed |Added
URL||google.com
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=109851
Malik Riaz changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |sujuvi...@techgroup.top
https://bugs.freedesktop.org/show_bug.cgi?id=109851
Bug ID: 109851
Summary: DGC is interlocking with SDIKS
Product: Mesa
Version: 10.0
Hardware: All
OS: All
Status: NEW
Severity: critical
On 05/03/2019 23:56, Brian Paul wrote:
And add/update comments.
---
src/gallium/auxiliary/util/u_bitmask.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_bitmask.c
b/src/gallium/auxiliary/util/u_bitmask.c
index
For the series,
Reviewed-by: Neha Bhende
Regards,
Neha
From: Brian Paul
Sent: Tuesday, March 5, 2019 7:48 PM
To: mesa-dev@lists.freedesktop.org
Cc: Neha Bhende; Deepak Singh Rawat; Thomas Hellstrom
Subject: [PATCH 3/3] winsys/svga: use new pb_usage_flags
On Wed, 6 Mar 2019 at 14:01, Brian Paul wrote:
>
>
> I guess I don't fully understand a few things about the new meson build.
>
> 1. I'm trying to build the gallium VMware driver with this:
>
> export BUILD_DIR=build-meson-dri
>
> mkdir "${BUILD_DIR}"
>
> meson -Dshared-llvm=false \
>
I guess I don't fully understand a few things about the new meson build.
1. I'm trying to build the gallium VMware driver with this:
export BUILD_DIR=build-meson-dri
mkdir "${BUILD_DIR}"
meson -Dshared-llvm=false \
-Dplatforms=x11,drm \
-Dgallium-drivers=svga \
Use a new enum type instead of 'unsigned' to make things a bit more
understandable.
---
src/gallium/auxiliary/pipebuffer/pb_buffer.h | 34 ++
.../auxiliary/pipebuffer/pb_buffer_fenced.c| 6 ++--
.../auxiliary/pipebuffer/pb_buffer_malloc.c| 4 +--
---
src/gallium/auxiliary/pipebuffer/pb_buffer.h | 101 +--
1 file changed, 49 insertions(+), 52 deletions(-)
diff --git a/src/gallium/auxiliary/pipebuffer/pb_buffer.h
b/src/gallium/auxiliary/pipebuffer/pb_buffer.h
index 11f70ea..bd60eba 100644
---
And add a comment that we're implicitly converting PIPE_TRANSFER_
flags to PB_USAGE_ flags in one place. And statically assert that
the enum values match.
---
src/gallium/winsys/svga/drm/vmw_buffer.c | 27 +++
src/gallium/winsys/svga/drm/vmw_buffer.h | 1 +
On Wed, 6 Mar 2019 at 01:01, Erik Faye-Lund
wrote:
>
> When we try to do a vrend transfer from a renderable texture, we end up
> using glReadPixels to read the data. However, OpenGL ES has
> restrictions on what formats are allowed to be used for glReadPixels.
> In partcular, only
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_assemble.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_assemble.c
b/src/gallium/drivers/panfrost/pan_assemble.c
index f3b339d8184..7e2f24edd71 100644
---
Series:
Reviewed-by: Timothy Arceri
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
This will allow us to query whether a context is valid.
In addition to keeping a list of contexts, we need to give each
context we create a unique ID which is never re-used. The screen
also contains a bitmask to track which IDs are valid. We need the
ID since a context pointer could be recycled
Some applications, like google-chrome, cause the state tracker to
destroy sampler/resource views from a context other than the one
which was used to create it. Previously, we just leaked the view.
Now, when we're in this situation we declare the view a zombie and
add it to a list of zombie views
Since OpenGL shaders may be shared among contexts, we can wind up
with variants of a shader created with different contexts.
When we go to destroy a shader variant, we want to free it with the
same context that it was created with.
This patch implements solves that problem.
The Redway3D Watch
And add/update comments.
---
src/gallium/auxiliary/util/u_bitmask.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_bitmask.c
b/src/gallium/auxiliary/util/u_bitmask.c
index 397b497..433a09d 100644
---
---
src/gallium/auxiliary/util/u_bitmask.c | 129 +
src/gallium/auxiliary/util/u_bitmask.h | 40 +-
2 files changed, 85 insertions(+), 84 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_bitmask.c
b/src/gallium/auxiliary/util/u_bitmask.c
index
There's no guarantee when build_deref_follower is called that the two
derefs have the same bit size destination. Insert a cast on the array
index in case we have differing bit sizes. While we're here, insert
some asserts in build_deref_array and build_deref_ptr_as_array. The
validator will
On Tue, Mar 05, 2019 at 07:50:24PM +, Chris Wilson wrote:
> Quoting Rafael Antognolli (2019-03-05 19:33:03)
> > On Tue, Mar 05, 2019 at 09:40:20AM +, Chris Wilson wrote:
> > > Not all commands support being preempted as they execute, and for those
> > > make sure we at least check for
Quoting Rafael Antognolli (2019-03-05 19:33:03)
> On Tue, Mar 05, 2019 at 09:40:20AM +, Chris Wilson wrote:
> > Not all commands support being preempted as they execute, and for those
> > make sure we at least check for being preempted before we start so as to
> > try and minimise the latency
On Tue, Mar 05, 2019 at 09:40:20AM +, Chris Wilson wrote:
> Not all commands support being preempted as they execute, and for those
> make sure we at least check for being preempted before we start so as to
> try and minimise the latency of whomever is more important than
> ourselves.
>
> Cc:
Alyssa Rosenzweig writes:
>> Alyssa: do you see any problem if we change to submit only one atom per
>> ioctl?
>
> I don't think so; aesthetically I don't like the extra kernel traffic,
> but that's not a real concern, and it sounds like that's the correct
> approach anyway.
>
> A big reason we
Kristian Høgsberg writes:
> On Mon, Mar 4, 2019 at 6:29 PM Dave Airlie wrote:
>>
>> On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg wrote:
>> >
>> > On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig
>> > wrote:
>> > >
>> > > > Why aren't we using regular dma-buf fences here? The submit ioctl
The hardware actually rounds before conversion. This now matches
what values are used when performing fast clears vs slow clears.
This fixes a rendering issue with Far Cry 3&4. This also fixes
a bunch of CTS tests that use a 8-bit UNORM format (only when
the 512*512 image size hint is manually
The mask should be accumulated if two calls are used for
binding two buffers at different indexes. Otherwise, the
driver only accounts for the last one.
Noticed while glancing at this code.
Cc: 18.3 19.0
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 2 +-
1 file
v2: - remove dead variables
Fixes: 58bcebd987b ("spirv: Allow [i/u]mulExtended to use new nir opcode")
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_nir_to_llvm.c | 34 +
1 file changed, 34 insertions(+)
diff --git a/src/amd/common/ac_nir_to_llvm.c
On 3/5/19 2:01 PM, Bas Nieuwenhuizen wrote:
On Tue, Mar 5, 2019 at 10:30 AM Samuel Pitoiset
wrote:
Fixes: 58bcebd987b ("spirv: Allow [i/u]mulExtended to use new nir opcode")
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_nir_to_llvm.c | 36 +
1 file
https://bugs.freedesktop.org/show_bug.cgi?id=109443
--- Comment #11 from William Deegan ---
I've pushed out an alpha package for you to verify your issue is now resolved.
https://github.com/SCons/scons/releases/tag/3.0.5a2
Also available at:
pip install --index-url
https://bugs.freedesktop.org/show_bug.cgi?id=109532
--- Comment #52 from asimiklit ---
Created attachment 143535
--> https://bugs.freedesktop.org/attachment.cgi?id=143535=edit
draft of a solution
Currently I am trying to find another way to fix this issue
to avoid removal of an optimization
> Alyssa: do you see any problem if we change to submit only one atom per
> ioctl?
I don't think so; aesthetically I don't like the extra kernel traffic,
but that's not a real concern, and it sounds like that's the correct
approach anyway.
A big reason we submit together on non-DRM is so we can
> One is that with kbase I don't see any noticeable pauses during the very
> first scene in glmark2.
...That sounds like a good thing? :)
> Another is that with the DRM driver I don't see the wallpaper in GNOME Shell.
GNOME Shell is very broken under Panfrost; that's not a kernel-space
> With non-DRM this code doesn't execute (at least on the workloads I tested
> with) because we don't support GEM handles for !scanout.
Gotcha, thank you.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
When we try to do a vrend transfer from a renderable texture, we end up
using glReadPixels to read the data. However, OpenGL ES has
restrictions on what formats are allowed to be used for glReadPixels.
In partcular, only GL_UNSIGNED_BYTE + GL_RGBA are guaranteed to be
supported (for OpenGL ES 2.0;
On Mon, Mar 4, 2019 at 6:43 PM Alyssa Rosenzweig wrote:
>
> Wooo!!!
>
> Seeing this patch in my inbox has been some of the best news all day!
>
> Without further ado, my (solicited?) comments:
>
> > +/* Copyright 2018, Linaro, Ltd., Rob Herring */
>
> Please triple check upstream that this
On 3/5/19 2:34 PM, Bas Nieuwenhuizen wrote:
On Tue, Mar 5, 2019 at 10:42 AM Samuel Pitoiset
wrote:
This fixes some CTS crashes with:
dEQP-VK.renderpass2.suballocation.attachment_write_mask.attachment_count_8.start_index_*
Ideally, we should check cmd_buffer->cs->max_dw because there is
On Tue, Mar 5, 2019 at 10:42 AM Samuel Pitoiset
wrote:
>
> This fixes some CTS crashes with:
> dEQP-VK.renderpass2.suballocation.attachment_write_mask.attachment_count_8.start_index_*
>
> Ideally, we should check cmd_buffer->cs->max_dw because there is
> likely enough space (the internal clear
On Tue, Mar 5, 2019 at 10:30 AM Samuel Pitoiset
wrote:
>
> Fixes: 58bcebd987b ("spirv: Allow [i/u]mulExtended to use new nir opcode")
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/common/ac_nir_to_llvm.c | 36 +
> 1 file changed, 36 insertions(+)
>
> diff
Reviewed-by: Bas Nieuwenhuizen
On Mon, Mar 4, 2019 at 2:22 PM Samuel Pitoiset
wrote:
>
> If alignement is 0, offets returned by
> radv_cmd_buffer_upload_alloc() are always 0. These two
> virtual addresses were pointing at the same location.
>
> v2: - add an asertion that checks if alignment is
Hello,
Could somebody take a look at this old patch?
Thanks,
Andrii.
On Tue, Nov 13, 2018 at 6:41 PM Eric Engestrom
wrote:
> On Tuesday, 2018-11-13 14:19:31 +0200, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit
> >
> > 1. main/texcompress_etc.c:1314:12:
> > warning: ‘*((void
On 3/5/19 11:09 AM, Chih-Wei Huang wrote:
Tapani Pälli 於 2019年3月5日 週二 下午4:48寫道：
On 3/5/19 9:26 AM, Chih-Wei Huang wrote:
Mauro Rossi 於 2019年3月4日 週一 上午3:58寫道：
Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
Rename the variable labels according to targets and
This fixes some CTS crashes with:
dEQP-VK.renderpass2.suballocation.attachment_write_mask.attachment_count_8.start_index_*
Ideally, we should check cmd_buffer->cs->max_dw because there is
likely enough space (the internal clear draws allocate space), but
keep that way for consistency.
Not all commands support being preempted as they execute, and for those
make sure we at least check for being preempted before we start so as to
try and minimise the latency of whomever is more important than
ourselves.
Cc: Jari Tahvanainen ,
Cc: Rafael Antognolli
Cc: Kenneth Graunke
---
Always
Not all commands support being preempted as they execute, and for those
make sure we at least check for being preempted before we start so as to
try and minimise the latency of whomever is more important than
ourselves.
Cc: Jari Tahvanainen ,
Cc: Rafael Antognolli
Cc: Kenneth Graunke
---
Fixes: 58bcebd987b ("spirv: Allow [i/u]mulExtended to use new nir opcode")
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_nir_to_llvm.c | 36 +
1 file changed, 36 insertions(+)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
Tapani Pälli 於 2019年3月5日 週二 下午4:48寫道：
>
> On 3/5/19 9:26 AM, Chih-Wei Huang wrote:
> > Mauro Rossi 於 2019年3月4日 週一 上午3:58寫道：
> >>
> >> Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
> >> Rename the variable labels according to targets and python scripts
> >> Align the
On 3/5/19 9:26 AM, Chih-Wei Huang wrote:
Mauro Rossi 於 2019年3月4日 週一 上午3:58寫道：
Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
Rename the variable labels according to targets and python scripts
Align the building rules as per Automake for simplification
Fixes
From: Mathias Fröhlich
Since mapping and unmapping the buffer objects in a VAO is handled
directly from the VAO, this part of the _NEW_ARRAY state is no longer
used. So remove this part of array element state.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/api_arrayelt.c | 95
From: Mathias Fröhlich
The standard requires that the primitive restart comparison happens before
the basevertex value is added. Do this now, drop a reference to the standard
why this happens at this place.
Signed-off-by: Mathias Fröhlich
---
src/mesa/vbo/vbo_save_api.c | 17 -
From: Mathias Fröhlich
Hi all,
The following series introduces functions to map and unmap all
vbos stored in a vao. Make use of those functions where possible.
On that way cleanup and fix what comes up along the way.
The series also already removes half of the state that is tracked
using the
From: Mathias Fröhlich
The maximum value primitive restart index is different for each index data
type. Use the appropriate fixed restart index value.
Signed-off-by: Mathias Fröhlich
---
src/mesa/vbo/vbo_save_api.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff
From: Mathias Fröhlich
Due to the use of bitmaps, the _mesa_vao_{,un}map_arrays functions
should provide comparable runtime efficienty to the currently used
_ae_{,un}map_vbos functions. So use this functions and enable
further cleanup.
Signed-off-by: Mathias Fröhlich
---
From: Mathias Fröhlich
The factored out function handles emitting the vertex attributes
at the given index. The now public accessible function gets used
in the following patches.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/api_arrayelt.c | 49 ++--
From: Mathias Fröhlich
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/draw.c | 57 ++--
1 file changed, 12 insertions(+), 45 deletions(-)
diff --git a/src/mesa/main/draw.c b/src/mesa/main/draw.c
index bfc4b9c9373..fa70463eaee 100644
---
From: Mathias Fröhlich
Provide a set of functions that maps or unmaps all VBOs held
in a VAO. The functions will be used in the following patches.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/arrayobj.c | 84
src/mesa/main/arrayobj.h | 18
From: Mathias Fröhlich
Make use of the newly factored out _mesa_array_element function
in display list compilation. For now that duplicates out the
primitive restart logic. But that turns out to need a fix in
display list handling anyhow.
Signed-off-by: Mathias Fröhlich
---
https://bugs.freedesktop.org/show_bug.cgi?id=109818
Samuel Pitoiset changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
70 matches
Mail list logo
