Z is 0 at the near plane and 1 at the far plane, but the planes can have an
arbitrary distance from the viewer, therefore Z Is irrelevant.
W is the real distance from the viewer. The greater W is, the smaller
(farther away) the object is, because W is the divisor (which makes objects
smaller as
https://bugs.freedesktop.org/show_bug.cgi?id=111290
Vinson Lee changed:
What|Removed |Added
Keywords||bisected
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=111290
Bug ID: 111290
Summary: undefined symbol _dri2_get_mapping_by_fourcc
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Mac OS X (All)
Status: NEW
Compare
generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-smooth-other-smooth-none.shader_test
generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-noperspective-other-smooth-none.shader_test
as you can see, the first one is perspective-interpolated and has a
IIRC, perspective interpolation is driven by W, not Z. Interpolating W and
then computing barycentric coordinates using 1/W is what causes the
perspective distortion.
Marek
On Fri, Aug 2, 2019 at 4:59 PM Ilia Mirkin wrote:
> On Fri, Aug 2, 2019 at 3:46 PM Gert Wollny
> wrote:
> >
> > Am
From: Marek Olšák
This only appears to happen on Raven2.
Possible way to reproduce:
resource_get_handle(WINSYS_HANDLE_TYPE_KMS) --> sets is_shared = true
resource_get_handle(WINSYS_HANDLE_TYPE_DMABUF) --> fail
Cc: 19.1 19.2
---
src/gallium/drivers/radeonsi/si_texture.c | 3 +--
1 file
From: Marek Olšák
---
src/mesa/state_tracker/st_cb_texture.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 0edb3ea5c7e..1ace61863ff 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++
https://bugs.freedesktop.org/show_bug.cgi?id=111288
--- Comment #1 from Greg ---
Created attachment 144935
--> https://bugs.freedesktop.org/attachment.cgi?id=144935=edit
glxinfo
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=111288
Bug ID: 111288
Summary: Memory leak in minecraft (supposedly related to
rendering)
Product: Mesa
Version: 19.1
Hardware: x86-64 (AMD64)
OS: Linux (All)
On Fri, Aug 2, 2019 at 3:03 PM Ian Romanick wrote:
>
> On 8/2/19 1:13 PM, Fritz Koenig wrote:
> > Hi,
> >
> > I would like to be able to use the MESA_framebuffer_flip_y extension
> > in GLES 3.0. The blocker is that FramebufferParameteri is not part of
> > GLES 3.0. I have explored a couple of
On 8/2/19 1:13 PM, Fritz Koenig wrote:
> Hi,
>
> I would like to be able to use the MESA_framebuffer_flip_y extension
> in GLES 3.0. The blocker is that FramebufferParameteri is not part of
> GLES 3.0. I have explored a couple of ways of achieving this.
>
> 1. FramebufferParameteri was first
I made another pass and I think I solved it in the correct way. I
think the problem was that the test needed to be updated to take into
consideration that the extension can apply to GLES 3.0 and not just
GLES 3.1.
On Fri, Aug 2, 2019 at 1:13 PM Fritz Koenig wrote:
>
> Hi,
>
> I would like to
On Fri, Aug 2, 2019 at 3:46 PM Gert Wollny wrote:
>
> 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
> >
Hi,
I would like to be able to use the MESA_framebuffer_flip_y extension
in GLES 3.0. The blocker is that FramebufferParameteri is not part of
GLES 3.0. I have explored a couple of ways of achieving this.
1. FramebufferParameteri was first provided by the GL extension
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
> > >
On 8/2/19 12:39 PM, Ian Romanick wrote:
> On 8/1/19 6:38 PM, Timothy Arceri wrote:
>> From the EGL_KHR_create_context spec:
>>
>>"* If OpenGL 3.1 is requested, the context returned may implement
>>any of the following versions:
>>
>> * Version 3.1. The GL_ARB_compatibility
On 8/1/19 6:38 PM, Timothy Arceri wrote:
> From the EGL_KHR_create_context spec:
>
>"* If OpenGL 3.1 is requested, the context returned may implement
>any of the following versions:
>
> * Version 3.1. The GL_ARB_compatibility extension may or may
>not be
On 8/2/19 9:12 AM, Brian Paul wrote:
> On 08/02/2019 09:56 AM, Eric Engestrom wrote:
>> On Friday, 2019-08-02 17:50:17 +0200, Michel Dänzer wrote:
>>> On 2019-08-02 5:37 p.m., Brian Paul wrote:
Ugh, I didn't mean to do this. I'm trying to figure out how to make a
merge request with
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
> > https://cgit.freedesktop.org/mesa/mesa/commit/?id=b048d8bf8f056759d1845a799d4ba2ac84bce30f
> > , which attempts to implement depth
https://bugs.freedesktop.org/show_bug.cgi?id=111264
Matt Turner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://bugs.freedesktop.org/show_bug.cgi?id=02
Roland Scheidegger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
R-b! Nice! :)
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
The wallpaper blit is a bit special in that the operation is targetting
the current FB, but the u_blitter logic creates a new surface for it
which makes util_framebuffer_state_equal() return false. In that case
we don't want a new FB descriptor to be emitted/attached, so let's just
copy the new
This guarantees that new draws targetting the same framebuffer will
get a new job instance.
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v2:
* Add Alyssa's R-b
---
src/gallium/drivers/panfrost/pan_job.c | 8
1 file changed, 8 insertions(+)
diff --git
From: Alyssa Rosenzweig
Rather than alloacting a huge (64MB) polygon list on context creation
and sharing it across framebuffers, we instead allocate polygon lists as
BOs (which consistently hit the cache) sized appropriately; for about a
month, we've known how to calculate the polygon list size
The patch looks good to me.
It replaces my earlier patch request on the same issue.
Reviewed-by: Charmaine Lee
On 8/2/19, 9:54 AM, "Brian Paul" wrote:
On 08/02/2019 10:36 AM, srol...@vmware.com wrote:
> From: Roland Scheidegger
>
> These versions still need wrapper but
Allows us to pass BOs without checking if they're NULL or not.
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v2:
* Add Alyssa's R-b
---
src/gallium/drivers/panfrost/pan_resource.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
No need to emit SFBD/MFBD at frame invalidation. They can be emitted
when the framebuffer is attached, which saves us a potential FB desc
re-allocation if a new FB is bound after the swap.
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v2:
* Add Alyssa's R-b
---
The FB desc will be emitted/attached on the first draw targetting
this new FB.
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v2:
* Add Alyssa's R-b
---
src/gallium/drivers/panfrost/pan_context.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff
The only user of this function always passes true.
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v2:
* Add Alyssa's R-b
---
src/gallium/drivers/panfrost/pan_context.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
Hello,
This patch series is getting rid of the 64MB polygon-list allocation
that was done at context init time in favor of a per-job polygon-list
allocation allowing us to shrink the BO size considerably and thus
reduce memory consumption.
The first 8 patches are random cleanups. Most of them
If the current FB matches the new one there's nothing to be done in
panfrost_set_framebuffer_state(). By bailing out early in that case we
avoid emitting new FB descriptors (the old ones are still valid).
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v2:
* Add
ctx->job is supposed to serve as a cache to avoid an hash table lookup
everytime we access the job attached to the currently bound FB, except
it was never assigned to anything but NULL.
Fix that by adding the missing assignment in panfrost_get_job_for_fbo().
Also add a missing NULL assignment in
Am 02.08.19 um 18:54 schrieb Brian Paul:
> On 08/02/2019 10:36 AM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> These versions still need wrapper but already have both success and
>> failure ordering.
>> (Compile tested on llvm 3.7, llvm 3.8.)
>>
>> Bugzilla:
On 08/02/2019 10:36 AM, srol...@vmware.com wrote:
From: Roland Scheidegger
These versions still need wrapper but already have both success and
failure ordering.
(Compile tested on llvm 3.7, llvm 3.8.)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=02
---
From: Roland Scheidegger
These versions still need wrapper but already have both success and
failure ordering.
(Compile tested on llvm 3.7, llvm 3.8.)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=02
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 16 +++-
1 file
On 2019-08-02 6:12 p.m., Brian Paul wrote:
> On 08/02/2019 09:56 AM, Eric Engestrom wrote:
>> On Friday, 2019-08-02 17:50:17 +0200, Michel Dänzer wrote:
>>> On 2019-08-02 5:37 p.m., Brian Paul wrote:
Ugh, I didn't mean to do this. I'm trying to figure out how to make a
merge request
On 08/02/2019 09:56 AM, Eric Engestrom wrote:
On Friday, 2019-08-02 17:50:17 +0200, Michel Dänzer wrote:
On 2019-08-02 5:37 p.m., Brian Paul wrote:
Ugh, I didn't mean to do this. I'm trying to figure out how to make a
merge request with gitlab.
Just push to a branch in your personal
On Friday, 2019-08-02 17:50:17 +0200, Michel Dänzer wrote:
> On 2019-08-02 5:37 p.m., Brian Paul wrote:
> > Ugh, I didn't mean to do this. I'm trying to figure out how to make a
> > merge request with gitlab.
>
> Just push to a branch in your personal repository, and the output of git
> push
On 2019-08-02 5:37 p.m., Brian Paul wrote:
> Ugh, I didn't mean to do this. I'm trying to figure out how to make a
> merge request with gitlab.
Just push to a branch in your personal repository, and the output of git
push contains an URL for creating an MR for it.
--
Earthling Michel Dänzer
> Was hitting a NULL pointer dereference when on the
> panfrost_bo_unreference(job->polygon_list) done in panfrost_free_job().
> Don't know having a NULL polygon_list is valid case (I guess that's
> possible for a job that does not involve the tiler) but I was facing
> this problem when running
Ugh, I didn't mean to do this. I'm trying to figure out how to make a
merge request with gitlab.
-Brian
On 08/02/2019 09:35 AM, GitLab Mirror wrote:
Module: Mesa
Branch: update-reviewers-for-vmware
Commit: a86eccfb78092493b3999849db62613838951756
URL:
> Note that before this patch, someone trying to get a new job for an FB
> that already has a job running would actually get the old job object
> and might start messing up with it. Not sure that's what we want.
I don't think that's what we want either, and I think I took pains to
ensure this
On Fri, 2 Aug 2019 08:12:15 -0700
Alyssa Rosenzweig wrote:
> So, in the future, we'll want to have multiple jobs for different
> framebuffers independently in flight at the same time. As an
> illustrative example, we would like the app to be able to do a sequence
> like:
>
> bind scanout
On Fri, 2 Aug 2019 07:59:02 -0700
Alyssa Rosenzweig wrote:
> Theoretically we were supposed to set ctx->job to the current job, I
> guess cacheing the result of panfrost_get_job_for_fbo()
>
> See v3d's implementation which this is a carbon clone of.
Okay, so it's something we want to have to
On Fri, 2 Aug 2019 08:14:05 -0700
Alyssa Rosenzweig wrote:
> Is there any cleanup we can simultaneously? (Where the check was done
> outside?) Or is this a futureproofing?
Was hitting a NULL pointer dereference when on the
panfrost_bo_unreference(job->polygon_list) done in panfrost_free_job().
https://bugs.freedesktop.org/show_bug.cgi?id=111272
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
R-b, but I guess I'm biased :)
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, 2 Aug 2019 08:00:28 -0700
Alyssa Rosenzweig wrote:
> What happens if the CPU creates jobs significiantly faster than the GPU
> processes them? Could you have four jobs for the same framebuffer in
> flight at once?
That's probably what will happen, yes.
>
> At present, we do some heavy
Is there any cleanup we can simultaneously? (Where the check was done
outside?) Or is this a futureproofing?
On Fri, Aug 02, 2019 at 12:12:56PM +0200, Boris Brezillon wrote:
> Allows us to pass BOs without checking if they're NULL or not.
>
> Signed-off-by: Boris Brezillon
> ---
>
R-b, I think.
On Fri, Aug 02, 2019 at 12:12:55PM +0200, Boris Brezillon wrote:
> The only user of this function always passes true.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_context.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff
So, in the future, we'll want to have multiple jobs for different
framebuffers independently in flight at the same time. As an
illustrative example, we would like the app to be able to do a sequence
like:
bind scanout
clear
draw something
bind FBO
clear
On 2019-08-01 6:51 p.m., Emil Velikov wrote:
> On Thu, 1 Aug 2019 at 16:03, Emil Velikov wrote:
>>
>> On Thu, 1 Aug 2019 at 14:26, Michel Dänzer wrote:
>>> On 2019-08-01 2:32 p.m., Emil Velikov wrote:
>>
Sure I'll do that in a moment.
>>>
>>> Why don't you just follow my suggestion above?
R-b, thank you especially for the comment deconstructing this magic.
On Fri, Aug 02, 2019 at 12:12:53PM +0200, Boris Brezillon wrote:
> The wallpaper blit is a bit special in that the operation is targetting
> the current FB, but the u_blitter logic creates a new surface for it
> which makes
R-b
On Fri, Aug 02, 2019 at 12:12:52PM +0200, Boris Brezillon wrote:
> If the current FB matches the new one there's nothing to be done in
> panfrost_set_framebuffer_state(). By bailing out early in that case we
> avoid emitting new FB descriptors (the old ones are still valid).
>
>
R-b, thank you :)
On Fri, Aug 02, 2019 at 12:12:51PM +0200, Boris Brezillon wrote:
> No need to emit SFBD/MFBD at frame invalidation. They can be emitted
> when the framebuffer is attached, which saves us a potential FB desc
> re-allocation if a new FB is bound after the swap.
>
> Signed-off-by:
What happens if the CPU creates jobs significiantly faster than the GPU
processes them? Could you have four jobs for the same framebuffer in
flight at once?
At present, we do some heavy flushing so "no" but in the future we'll
want to lax up for performance.
On Fri, Aug 02, 2019 at 12:12:50PM
Theoretically we were supposed to set ctx->job to the current job, I
guess cacheing the result of panfrost_get_job_for_fbo()
See v3d's implementation which this is a carbon clone of.
On Fri, Aug 02, 2019 at 12:12:49PM +0200, Boris Brezillon wrote:
> This field is never set to anything but NULL,
https://bugs.freedesktop.org/show_bug.cgi?id=111272
--- Comment #15 from Parker Reed ---
Ahh thanks. Wasn't aware of that. This can be closed out in that case. I'll bug
the software I was using about not setting the DRI_PRIME in certain cases.
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=111272
--- Comment #14 from Michel Dänzer ---
(In reply to Parker Reed from comment #13)
> But the Intel card isn't enabled in the conf.
That doesn't matter with DRI3. With it, libGL can use an alternative GPU
without any explicit support for it in
https://bugs.freedesktop.org/show_bug.cgi?id=111272
--- Comment #13 from Parker Reed ---
But the Intel card isn't enabled in the conf. Why is it trying to init it if
it's not there? i915 is loaded kernel side but it's just dead displaying a TTY.
I agree the DRI_PRIME shouldn't be called in
https://bugs.freedesktop.org/show_bug.cgi?id=111272
--- Comment #12 from Michel Dänzer ---
In other words, the only thing preventing the Intel GPU from being used in this
case is the i965 driver missing the blitImage functionality.
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=111272
--- Comment #11 from Michel Dänzer ---
(In reply to Parker Reed from comment #10)
> So would DRI_PRIME=1 acting like 0 if only one GPU is present, be a
> possibility? The fact it's trying to load the non-existent GPU
It's not really
https://bugs.freedesktop.org/show_bug.cgi?id=111272
--- Comment #10 from Parker Reed ---
So would DRI_PRIME=1 acting like 0 if only one GPU is present, be a
possibility? The fact it's trying to load the non-existent GPU in the first
place seems to be the root issue.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=111272
--- Comment #9 from Parker Reed ---
I need to wakeup and read the comment. So it's because DRI2. Thanks for the
reply.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=111272
--- Comment #8 from Parker Reed ---
Aye, I was more intrigued by the vsync bypass. It even uncapped games with a
forced 60 (regardless of vsync being on or off)
Just a consequence of that DRI fallback?
--
You are receiving this mail because:
The driver should now rely on cmask_offset because CMASK can be
disabled by the driver for some reasons (eg. mipmaps). Apply the
same change for FMASK, although it should be useless.
Fixes: ad1bc8621df ("radv: remove radv_get_image_fmask_info()")
Fixes: 10d08da52c6 ("radv/gfx10: add missing
https://bugs.freedesktop.org/show_bug.cgi?id=41
--- Comment #22 from Steven Newbury ---
Essentially reverting 3371de38f282c77461bbe5007a2fec2a975776df makes it work...
...why?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
r-b for both
On Thu, Aug 1, 2019 at 3:41 PM Samuel Pitoiset
wrote:
>
> It's 0 for depth surfaces with TC compat HTILE enabled.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_image.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
r-b for both
On Thu, Aug 1, 2019 at 5:56 PM Samuel Pitoiset
wrote:
>
> It's unnecessary to duplicate fields in another struct.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_device.c | 4 ++--
> src/amd/vulkan/radv_image.c | 38 +---
>
LGTM
Reviewed-by: Neha Bhende
Regards,
Neha
From: Charmaine Lee
Sent: Thursday, August 1, 2019 3:56 PM
To: mesa-dev@lists.freedesktop.org; Brian Paul; Neha Bhende; Roland
Scheidegger; Jose Fonseca; airl...@redhat.com
Cc: Charmaine Lee
Subject: [PATCH]
Allows us to pass BOs without checking if they're NULL or not.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_resource.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
The FB desc will be emitted/attached on the first draw targetting
this new FB.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
If the current FB matches the new one there's nothing to be done in
panfrost_set_framebuffer_state(). By bailing out early in that case we
avoid emitting new FB descriptors (the old ones are still valid).
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 4
1
This field is never set to anything but NULL, which means the test
done in panfrost_free_job() and panfrost_get_job_for_fbo() will always
evaluate to false. Let's get rid of this field.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.h | 3 +--
Hello,
This patch series is getting rid of the 64MB polygon-list allocation
that was done at context init time in favor of a per-job polygon-list
allocation allowing us to shrink the BO size considerably and thus
reduce memory consumption.
The first 8 patches are random cleanups. Most of them
This guarantees that new draws targetting the same framebuffer will
get a new job instance.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_job.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/panfrost/pan_job.c
From: Alyssa Rosenzweig
Rather than alloacting a huge (64MB) polygon list on context creation
and sharing it across framebuffers, we instead allocate polygon lists as
BOs (which consistently hit the cache) sized appropriately; for about a
month, we've known how to calculate the polygon list size
The wallpaper blit is a bit special in that the operation is targetting
the current FB, but the u_blitter logic creates a new surface for it
which makes util_framebuffer_state_equal() return false. In that case
we don't want a new FB descriptor to be emitted/attached, so let's just
copy the new
No need to emit SFBD/MFBD at frame invalidation. They can be emitted
when the framebuffer is attached, which saves us a potential FB desc
re-allocation if a new FB is bound after the swap.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 21 ++---
The only user of this function always passes true.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
https://bugs.freedesktop.org/show_bug.cgi?id=111272
Michel Dänzer changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
Hi all
I would suggest to add this issue to the release -
https://bugs.freedesktop.org/show_bug.cgi?id=110814
Since, the isn't actual with 19.0 version of the Mesa - it's a regression
issue and we proposed the fix to it and would ask to merge it to 19.2
release it in this release.
Regards,
Paul
Looks good to me.
Reviewed-by: Jose Fonseca
From: Charmaine Lee
Sent: Thursday, August 1, 2019 23:56
To: mesa-dev@lists.freedesktop.org ; Brian Paul
; Neha Bhende ; Roland Scheidegger
; Jose Fonseca ; airl...@redhat.com
Cc: Charmaine Lee
Subject: [PATCH]
On Thursday, August 1, 2019 6:38:45 PM PDT Timothy Arceri wrote:
> From the EGL_KHR_create_context spec:
>
>"* If OpenGL 3.1 is requested, the context returned may implement
>any of the following versions:
>
> * Version 3.1. The GL_ARB_compatibility extension may or may
>
86 matches
Mail list logo
