By default, we call back the driver's hook fallback function that has generic
implementations for the all the queries.
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
src/mesa/drivers/dri/i965/brw_context.c | 1 +
src/mesa/drivers/dri/i965/brw_context.h | 5
src/mesa/drivers
From: Antia Puentes
It will be used by the ARB_internalformat_query2 implementation
to check if a certain compressed 'internalformat' is supported
by texture 'targets'.
---
src/mesa/main/teximage.c | 2 +-
src/mesa/main/teximage.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --
From: Antia Puentes
The goal is to extend the GetInternalformativ query to implement the
ARB_internalformat_query2 specification, keeping the behaviour defined
by the ARB_internalformat_query if ARB_internalformat_query2 is not
supported.
---
src/mesa/main/formatquery.c | 440 +++
From: Antia Puentes
The ARB_internalformat_query2 specification defines which is the
reponse best representing "not supported" or "not applicable" for
each .
Queries for unsupported features, targets, internalformats, combinations
of: target and internalformat, target and pname, pname and intern
From: Antia Puentes
Handles the cases where an error should be returned according
to the ARB_internalformat_query and ARB_internalformat_query2
specifications.
---
src/mesa/main/formatquery.c | 228
1 file changed, 228 insertions(+)
diff --git a/src/
Now that there is a dedicated source file for internal format queries, this
function belongs there.
---
src/mesa/drivers/dri/i965/brw_context.c | 38
src/mesa/drivers/dri/i965/brw_context.h | 2 ++
src/mesa/drivers/dri/i965/brw_formatquery.c | 39 +
From: Antia Puentes
From the ARB_internalformat_query2 specification:
"The INTERNALFORMAT_SUPPORTED can be used to determine if
the internal format is supported, and the other are defined
in terms of whether or not the format is supported."
---
src/mesa/main/formatquery.c | 34 ++
Implements SAMPLES and NUM_SAMPLE_COUNTS queries using the new generic
driver call QueryInternalFormat, which is being introduced as replacement
of QuerySamplesForFormat to support ARB_internalformat_query2.
---
src/mesa/main/formatquery.c | 42 ++
1 file ch
From: Antia Puentes
---
src/mesa/main/formatquery.c | 16
src/mesa/main/formatquery.h | 4
2 files changed, 20 insertions(+)
diff --git a/src/mesa/main/formatquery.c b/src/mesa/main/formatquery.c
index 8d0cded..f9795ae 100644
--- a/src/mesa/main/formatquery.c
+++ b/src/me
This is a fallback function for drivers not implementing
ARB_internalformat_query2.
---
src/mesa/drivers/common/driverfuncs.c | 1 +
src/mesa/main/formatquery.c | 16
src/mesa/main/formatquery.h | 5 +
3 files changed, 22 insertions(+)
diff --git a/src/m
This new function queries different driver parameters for a particular target
and texture format. It is basically a driver hook to support
ARB_internalformat_query2.
Since ARB_internalformat_query2 introduced several new query parameters
over ARB_internalformat_query, having one driver hook for ea
Hello,
This is an RFC series adding support for the ARB_internalformat-query2
extension:
https://www.opengl.org/registry/specs/ARB/internalformat_query2.txt
The corresponding bug is being tracked at:
https://bugs.freedesktop.org/show_bug.cgi?id=92687
Why is this an RFC series instead of a for
On Tue, Jan 19, 2016 at 5:20 PM, Axel Davy wrote:
> On 19/01/2016 17:11, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> because not using SPI_SHADER_32_ABGR doubles fill rate.
>>
>> We should also get optimal performance if alpha isn't needed or blending
>> isn't enabled.
>> ---
>> src/galliu
FWIW why exactly are pipe_sampler_view and pipe_surface ref counted?
These are all the same too from a high level perspective.
I guess though there'd be significant effort to change that...
Roland
Am 19.01.2016 um 04:08 schrieb Ilia Mirkin:
> Make them akin to shader buffers, with no refcounting
On 19/01/2016 17:11, Marek Olšák wrote:
From: Marek Olšák
because not using SPI_SHADER_32_ABGR doubles fill rate.
We should also get optimal performance if alpha isn't needed or blending
isn't enabled.
---
src/gallium/drivers/radeon/r600_pipe_common.h | 6 +-
src/gallium/drivers/radeons
From: Marek Olšák
This avoids the fp16 packing instructions.
---
src/gallium/drivers/radeonsi/si_state_shaders.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 73a0ccc..1
From: Marek Olšák
most likely useless, but doesn't hurt
---
src/gallium/drivers/radeonsi/si_state.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 2a6d2c6..ea441ac 100644
--- a/src/gallium/drivers/ra
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.h| 4
src/gallium/drivers/radeonsi/si_state_shaders.c | 12
2 files changed, 16 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_shader.h
b/src/gallium/drivers/radeonsi/si_shader.h
index f49290a..
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_state_shaders.c | 52 +
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index fa78179..73a0ccc 100644
-
Hi,
This series adds support for all pixel shader export formats. It should double
the fill rate for these formats:
- 1-4 channels of type S/UINT8, S/UINT16, S/UNORM16
- 1-2 channels of type S/UINT32, FLOAT32
Some of them have to fall back to the original slow mode depending on whether
blending
From: Marek Olšák
This does change the behavior slightly:
If a shader writes COLOR[i] and that color buffer isn't bound,
the shader will export MRT_NULL instead and discard the IR tree that
calculates the output. The only exception is alpha-to-coverage, which
requires an alpha export.
---
On 19.01.2016 10:45, Fredrik Höglund wrote:
On Tuesday 19 January 2016, Nicolai Hähnle wrote:
On 18.01.2016 18:50, Ilia Mirkin wrote:
On Mon, Jan 18, 2016 at 5:22 PM, Nicolai Hähnle wrote:
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
b/src/gallium/drivers/nouveau/nv30/nv30_sc
From: Marek Olšák
because not using SPI_SHADER_32_ABGR doubles fill rate.
We should also get optimal performance if alpha isn't needed or blending
isn't enabled.
---
src/gallium/drivers/radeon/r600_pipe_common.h | 6 +-
src/gallium/drivers/radeonsi/si_blit.c | 8 +
src/gallium/dr
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 153 ---
src/gallium/drivers/radeonsi/si_shader.h | 1 +
2 files changed, 140 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_sh
On Tuesday 19 January 2016, Nicolai Hähnle wrote:
>
> On 18.01.2016 18:50, Ilia Mirkin wrote:
> > On Mon, Jan 18, 2016 at 5:22 PM, Nicolai Hähnle wrote:
> >> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> >> b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> >> index 90f..1ae5
On 18.01.2016 22:08, Ilia Mirkin wrote:
Make them akin to shader buffers, with no refcounting/etc. Just used to
pass data about the bound image in ->set_shader_images.
Signed-off-by: Ilia Mirkin
---
I don't really see a reason why these were refcounted objects. It seems like
it would be conven
dEQP tests request a specific version. The EXT spec has been updated to
allow other versions, so allow anything >= 2.0 to be requested.
Signed-off-by: Ilia Mirkin
---
The X server was also blocking this... a patch has been sent (pending
moderator approval).
src/glx/dri_common.c | 9 -
On Tue, Jan 19, 2016 at 1:48 PM, Emil Velikov wrote:
>
> Marek Olšák (3):
> program: add _mesa_reserve_parameter_storage
> st/mesa: fix GLSL uniform updates for glBitmap & glDrawPixels (v2)
>
> * Marek can we please get a backport for the latter ? Alternatively
> can we drop then both,
On 01/19/2016 07:37 AM, Ilia Mirkin wrote:
On Tue, Jan 19, 2016 at 9:34 AM, Brian Paul wrote:
I don't have any issue with simply adding PROGRAM_BUFFER to the enum type.
prog_src_register::File is a 4-bit field and we currently have 13 enum
values so we're safe there (not sure if that even matte
On Tue, Jan 19, 2016 at 9:34 AM, Brian Paul wrote:
> I don't have any issue with simply adding PROGRAM_BUFFER to the enum type.
> prog_src_register::File is a 4-bit field and we currently have 13 enum
> values so we're safe there (not sure if that even matters).
That's cutting it close... 13 = im
I don't have any issue with simply adding PROGRAM_BUFFER to the enum
type. prog_src_register::File is a 4-bit field and we currently have 13
enum values so we're safe there (not sure if that even matters).
I know I've used gdb to debug/trace something in st_glsl_to_tgsi.cpp at
least twice las
On 01/19/2016 06:24 AM, Daniel Stone wrote:
Hi,
On 19 January 2016 at 02:14, Timothy Arceri
wrote:
On Mon, 2016-01-18 at 16:47 +0100, Jouk Jansen wrote:
Can someone insert these patches in the git-repository.
I cannot do it myself, because the git-client on my OpenVMS is very
-very
limited an
Because I got a ton of errors about how PROGRAM_BUFFER was out of
bounds for the enum. I could add them to the enum, of course, but I
think that enum was about ARB_vp/fp things?
-ilia
On Tue, Jan 19, 2016 at 9:23 AM, Brian Paul wrote:
> Can you say why you're removing gl_register_file? Enums
Can you say why you're removing gl_register_file? Enums are so much
nicer when debugging.
-Brian
On 01/18/2016 07:30 PM, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
Reviewed-by: Marek Olšák
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 21 +++--
1 file changed, 11 in
Hi,
On 19 January 2016 at 02:14, Timothy Arceri
wrote:
> On Mon, 2016-01-18 at 16:47 +0100, Jouk Jansen wrote:
>> Can someone insert these patches in the git-repository.
>> I cannot do it myself, because the git-client on my OpenVMS is very
>> -very
>> limited and does not allow this.
>
> Why not
Jeremy, did you have a chance to test this patch?
This patch would be still useful for OS X. For non-OS X this patch [1]
reduces the size of libGL.so further more.
Thanks,
Andreas
[1] https://patchwork.freedesktop.org/patch/70372/
2015-09-28 19:46 GMT+02:00 Jeremy Huddleston Sequoia :
> I'll giv
Hi all,
It's time to get the idea of where were are wrt the next Mesa release
- 11.2.0. As usual here is the normal plan, although everyone
interested in more than welcome to chime in
February 19th 2016 - Feature freeze/Release candidate 1
February 26th 2016 - Release candidate 2
March 04th 2016
Thanks for reviewing!
Oh, I was motivated to do this patch to remove an unneeded symbol on
linux as we started tracking libGL's exported symbols in Debian.
As a side effect it accelerates the build a bit and reduces the size
of libGL significantly.
From looking at these threads [1][2] I found out
Hello list,
The candidate for the Mesa 11.0.9 is now available. Currently we have:
- 22 queued
- 20 nominated (outstanding)
- and 1 rejected/obsolete patches
Current queue addressed a few important driver issues - nouveau
(sluggish 4K decoding, pushbuf/bufctx management), i965 (EGL crash),
r60
Reviewed-by: Marta Lofstedt
> -Original Message-
> From: Francisco Jerez [mailto:curroje...@riseup.net]
> Sent: Monday, January 18, 2016 9:37 PM
> To: mesa-dev@lists.freedesktop.org
> Cc: Lofstedt, Marta; Justen, Jordan L
> Subject: [PATCH 2/2] i965: Implement compute sampler state atom.
Thanks Curro,
Reviewed-by: Marta Lofstedt
> -Original Message-
> From: Francisco Jerez [mailto:curroje...@riseup.net]
> Sent: Monday, January 18, 2016 9:37 PM
> To: mesa-dev@lists.freedesktop.org
> Cc: Lofstedt, Marta; Justen, Jordan L
> Subject: [PATCH 1/2] i965: Trigger CS state reemi
Hi,
On 19.01.2016 13:07, Marek Olšák wrote:
On Mon, Jan 18, 2016 at 6:12 PM, Eero Tamminen
On 18.01.2016 17:05, Kenneth Graunke wrote:
[...]
If one wants startup shaders not to be overwritten, one can just kill the
program at that point. One could also somewhat differentiate shaders to
diffe
On 01/19/2016 01:14 PM, Ilia Mirkin wrote:
The data structure is a (memory) heap... there appears to be one in
mesa/main/mm.h. There's also one in nouveau_heap.h which is quite
simple and totally unreliant on nouveau, just happens to be there. How
hard would it be to integrate something like th
The data structure is a (memory) heap... there appears to be one in
mesa/main/mm.h. There's also one in nouveau_heap.h which is quite
simple and totally unreliant on nouveau, just happens to be there. How
hard would it be to integrate something like that?
The trouble with adding slow things is tha
On Tue, Jan 19, 2016 at 5:49 AM, Marek Olšák wrote:
> On Tue, Jan 19, 2016 at 3:25 AM, Ilia Mirkin wrote:
>> On Mon, Jan 18, 2016 at 6:06 AM, Marek Olšák wrote:
>>> For 1-4,
>>>
>>> Reviewed-by: Marek Olšák
>>>
>>> I'm not very familiar with the code in 2, but the changes seem reasonable.
>>>
>
On Mon, Jan 18, 2016 at 6:12 PM, Eero Tamminen
wrote:
> Hi,
>
> On 18.01.2016 17:05, Kenneth Graunke wrote:
>>
>> This writes linked shader programs to .shader_test files to
>> $MESA_SHADER_CAPTURE_PATH in the format used by shader-db
>> (http://cgit.freedesktop.org/mesa/shader-db).
>>
>> It suppo
This seem a bit suboptimal, since the same space is potentially searched
multiple times. However, I believe that a better solution would be to use some
other data structure which would probably require quite a big effort, so for
now, this is:
Reviewed-by: Marta Lofstedt
> -Original Messa
Reviewed-by: Marek Olšák
Marek
On Tue, Jan 19, 2016 at 3:30 AM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
>
> v1 -> v2: use TGSI_MEMBAR defines
> ---
> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 45
> ++
> 1 file changed, 45 insertions(+)
>
> diff --git a/
On Tue, Jan 19, 2016 at 3:25 AM, Ilia Mirkin wrote:
> On Mon, Jan 18, 2016 at 6:06 AM, Marek Olšák wrote:
>> For 1-4,
>>
>> Reviewed-by: Marek Olšák
>>
>> I'm not very familiar with the code in 2, but the changes seem reasonable.
>>
>> Also, and I know this is not your mistake, but still, mtypes
Patch moves uniform calculation to happen during link_uniforms, this
is possible with help of UniformRemapTable that has all the reserved
locations.
Location assignment for implicit locations is changed so that we
utilize also the 'holes' that explicit uniform location assignment
might have left i
101 - 150 of 150 matches
Mail list logo
