Hello Marta,
I have quickly searched the constants in OpenGL ES 3.1 spec but I have
not found some of them. As I could do a wrong search, please check if
they are defined or not.
Thanks,
Sam
On 23/07/15 16:38, Marta Lofstedt wrote:
> This is V5 of my patch-set for enabling extension enums for
>
On 23/07/15 16:38, Marta Lofstedt wrote:
> From: Marta Lofstedt
>
> Signed-off-by: Marta Lofstedt
> ---
> src/mesa/main/get.c | 6 ++
> src/mesa/main/get_hash_params.py | 17 +++--
> 2 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/mai
On 23/07/15 16:38, Marta Lofstedt wrote:
> From: Marta Lofstedt
>
> Signed-off-by: Marta Lofstedt
> ---
> src/mesa/main/get.c | 6 ++
> src/mesa/main/get_hash_params.py | 18 +-
> 2 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/src/mesa/ma
On 23/07/15 16:38, Marta Lofstedt wrote:
> From: Marta Lofstedt
>
> Signed-off-by: Marta Lofstedt
> ---
> src/mesa/main/get.c | 6 ++
> src/mesa/main/get_hash_params.py | 10 +-
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/main/get.c
On Fri, 2015-07-24 at 16:20 +0300, Francisco Jerez wrote:
> Iago Toral Quiroga writes:
>
> > Larger registers should have been moved to scratch (like GRF array access)
> > or split to size 1 by the split_virtual_grfs pass.
>
> Not necessarily. split_virtual_grfs() won't be able to split stuff
>
On Fri, 2015-07-24 at 16:18 +0300, Francisco Jerez wrote:
> Iago Toral Quiroga writes:
>
> > When we have code such as this:
> >
> > mov vgrf1.0.x:F, vgrf2.:F
> > mov vgrf3.0.x:F, vgrf1.:F
> > ...
> > mov vgrf3.0.x:F, vgrf1.:F
> >
> > And vgrf1 is chosen for spilling, we can emit this
Reviewed-by: Samuel Iglesias Gonsálvez
Sam
On 25/07/15 07:06, Ilia Mirkin wrote:
> Add in missed version checks in the GLSL parser
>
> Signed-off-by: Ilia Mirkin
> ---
>
> v1 -> v2: drop AoA hunks to avoid conflicting with Timothy's changes
>
> src/glsl/glsl_parser.yy | 5 +++--
> 1 file ch
From: Dave Airlie
This was missed when I did fp64, I've sent a piglit test to cover
the case as well.
Signed-off-by: Dave Airlie
---
src/mesa/main/uniform_query.cpp | 15 +++
src/mesa/main/uniforms.c| 9 -
2 files changed, 11 insertions(+), 13 deletions(-)
diff --
On 27 July 2015 at 11:50, Dave Airlie wrote:
> From: Dave Airlie
>
> This enables GL4.1 for radeonsi, and updates the
> docs in the correct places.
>
self review suggests this should probably be gated on LLVM 3.7.
Dave.
___
mesa-dev mailing list
mesa-d
Pretty much what it says, the multiple stream work and repost
of interpolateAt bits, with final patch to turn stuff on.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
From: Dave Airlie
This enables GL4.1 for radeonsi, and updates the
docs in the correct places.
Signed-off-by: Dave Airlie
---
docs/GL3.txt | 16
docs/relnotes/10.7.0.html | 1 +
src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
3 files cha
From: Dave Airlie
This will be used here later.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/radeon/r600_streamout.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_streamout.c
b/src/gallium/drivers/radeon/r600_streamout.c
i
From: Dave Airlie
This is part of ARB_gpu_shader5, and this passes
all the piglit tests currently available.
v2: use macros from the fine derivs commit.
add comments.
Signed-off-by: Dave Airlie
---
docs/GL3.txt | 2 +-
src/gallium/drivers/radeonsi/si_shader.c | 24
From: Dave Airlie
This is the final piece for ARB_gpu_shader5,
The code is based on the r600 code from Glenn Kennard,
and myself.
While developing this, I'm not 100% sure of all the calculations
made in the GS registers, this is why the max_stream is worked
out there and used to limit the chang
From: Dave Airlie
This adds to the common radeon streamout code, support
for multiple streams.
It updates radeonsi/r600 to set the enabled mask up.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 7 +++
src/gallium/drivers/r600/r600_shader.h | 1
From: Dave Airlie
This adds support for queries against the non-0 vertex streams.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/radeon/r600_query.c | 18 --
src/gallium/drivers/radeon/r600d_common.h | 3 +++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git
> Why? Your module::argument::image_size and ::image_format cases don't
> touch the explicit_arg iterator at all AFAICT, so it will be left
> pointing one past the last general semantic argument
Ok, my mistake, I didn't think this through.
> Hmmm... So you only need it as padding? Wouldn't it
On 07/24/2015 11:53 PM, Jason Ekstrand wrote:
> On Fri, Jul 24, 2015 at 12:19 PM, Jason Ekstrand wrote:
>> On Thu, Jul 23, 2015 at 3:16 AM, Eduardo Lima Mitev wrote:
>>> These methods are essential for the implementation of the NIR->vec4 pass.
>>> They
>>> work similar to their fs_nir counter-pa
On 07/25/2015 12:08 AM, Jason Ekstrand wrote:
> On Thu, Jul 23, 2015 at 3:17 AM, Eduardo Lima Mitev wrote:
>> The destination register from the instruction is stored in the output_reg
>> variable at its original varying value. From there, vec4_visitor's
>> emit_urb_slot() will pick it up and conti
On Jul 26, 2015 2:09 PM, "Eduardo Lima Mitev" wrote:
>
> On 07/25/2015 12:04 AM, Jason Ekstrand wrote:
> > I think we already agreed to just copy data.location into
> > data.driver_location and we don't need this special-casing.
> >
> > Just making a note of it as I review.
> > --Jason
> >
>
> Yes
On 07/25/2015 12:04 AM, Jason Ekstrand wrote:
> I think we already agreed to just copy data.location into
> data.driver_location and we don't need this special-casing.
>
> Just making a note of it as I review.
> --Jason
>
Yes, I have completely removed this patch from the series. Now all the
agr
On Jul 26, 2015 1:40 PM, "Eduardo Lima Mitev" wrote:
>
> On 07/23/2015 11:25 PM, Jason Ekstrand wrote:
> > On Thu, Jul 23, 2015 at 3:16 AM, Eduardo Lima Mitev
wrote:
> >> The NIR->vec4 pass will be activated if both the following conditions
are met:
> >>
> >> * INTEL_USE_NIR environment variable
On 07/24/2015 12:31 AM, Jason Ekstrand wrote:
> On Thu, Jul 23, 2015 at 3:16 AM, Eduardo Lima Mitev wrote:
>> The upcoming introduction of NIR->vec4 pass will require that some NIR
>> lowering
>> passes are enabled/disabled depending on the type of shader (scalar vs.
>> vector).
>>
>> With this
On 07/23/2015 11:25 PM, Jason Ekstrand wrote:
> On Thu, Jul 23, 2015 at 3:16 AM, Eduardo Lima Mitev wrote:
>> The NIR->vec4 pass will be activated if both the following conditions are
>> met:
>>
>> * INTEL_USE_NIR environment variable is defined and is positive (1 or true)
>> * The stage is verte
https://bugs.freedesktop.org/show_bug.cgi?id=91456
Lorenzo Bona changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=91468
--- Comment #1 from Lorenzo Bona ---
(In reply to Krzysztof A. Sobiecki from comment #0)
> Created attachment 117384 [details] [review]
> A patch?
>
> LLVM 3.8(svn): llvm-config-3.8 output for "--version" have "svn" in it, but
> shared library f
https://bugs.freedesktop.org/show_bug.cgi?id=91468
Lorenzo Bona changed:
What|Removed |Added
CC||lorenz.b...@gmail.com
--- Comment #2 from
https://bugs.freedesktop.org/show_bug.cgi?id=91468
Bug ID: 91468
Summary: LLVM 3.8(svn): llvm changes llvm-config output again?
Product: Mesa
Version: git
Hardware: All
OS: All
Status: NEW
Severity: normal
Mesa 10.6.3 is now available.
This release mostly consists of nouveau bugfixes, although we do
have some patches for the VL module (affecting VDPAU/VAAPI/OMX),
XA (memory leak) and osmesa (long standing typo in
OSMesaGetProcAddress/OSMesaPixelsStore).
Brian Paul (1):
osmesa: fix OSMesaPixel
---
src/gallium/state_trackers/clover/api/program.cpp | 33 ++
src/gallium/state_trackers/clover/core/program.hpp | 4 +--
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/api/program.cpp
b/src/gallium/state_trackers/clover/ap
Zoltán Gilián writes:
>> auto img = dynamic_cast(**(explicit_arg - 1))
>
> Ok, so it should be (explicit_arg - 2) for the image format, I
> presume.
Why? Your module::argument::image_size and ::image_format cases don't
touch the explicit_arg iterator at all AFAICT, so it will be left
pointing o
> auto img = dynamic_cast(**(explicit_arg - 1))
Ok, so it should be (explicit_arg - 2) for the image format, I
presume. This will be incorrect, however, if the targets that need
implicit argument for format metadata are indeed a strict superset of
the ones that need dimension, as you mentioned bef
EdB writes:
> ---
> src/gallium/state_trackers/clover/api/program.cpp | 33
> +++
> 1 file changed, 33 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/api/program.cpp
> b/src/gallium/state_trackers/clover/api/program.cpp
> index 553bc83..086f952 100644
> --
https://bugs.freedesktop.org/show_bug.cgi?id=91020
Pali Rohár changed:
What|Removed |Added
CC||pali.ro...@gmail.com
--
You are receiving
On Sun, 2015-07-26 at 03:04 +0200, Erik Faye-Lund wrote:
> On Sat, Jul 25, 2015 at 4:24 PM, Timothy Arceri
> wrote:
> > Since commit c0cd5b var->data.binding was being used as a replacement
> > for atomic buffer index, but they don't have to be the same value they
> > just happen to end up the sa
On Sat, 2015-07-25 at 18:11 +0200, Alejandro Piñeiro wrote:
> Hi Timothy,
>
> thanks for CCing me. Just to say that it looks good to me. And FWIW,
> with this patch, the piglit subtest included on the second version of my
> patch (second version after the first review of Ian Romanick) here:
>
>
Since commit c0cd5b var->data.binding was being used as a replacement
for atomic buffer index, but they don't have to be the same value they
just happen to end up the same when binding is 0.
Now we store atomic buffer index in the unused var->data.index
to avoid the extra memory of putting back th
On 07/26/2015 06:56 AM, Ilia Mirkin wrote:
Apparently this is necessary in order for tess factors to work in a tess
eval program without a tess control program bound. Probably because it
uses the fake program's shader header to work out the number of patch
constants.
Fixes vs-tes-tessinner-tes
38 matches
Mail list logo
