https://bugs.freedesktop.org/show_bug.cgi?id=85203
Michel Dänzer changed:
What|Removed |Added
CC||mario.klei...@tuebingen.mpg
On Tue, Nov 25, 2014 at 1:19 AM, Jason Ekstrand wrote:
> Previously, the hash_table API required the user to do all of the hashing
> of keys as it passed them in. Since the hashing function is intrinsicly
> tied to the comparison function, it makes sense for the hash table to know
> about it. Al
Hi,
This patch removes the tripple buffering behaviour that the GLX
implementation
has with DRI3. I understand your concern for Medical softwares,
but perhaps this would be better handled with an user option.
Axel Davy
On 25/11/2014 04:00, Mario Kleiner wrote :
Restores proper immediate tear
If people like this change, I'll do the same thing to the hash set
implementation.
--Jason
On Mon, Nov 24, 2014 at 10:19 PM, Jason Ekstrand
wrote:
> Previously, the hash_table API required the user to do all of the hashing
> of keys as it passed them in. Since the hashing function is intrinsicl
Previously, the hash_table API required the user to do all of the hashing
of keys as it passed them in. Since the hashing function is intrinsicly
tied to the comparison function, it makes sense for the hash table to know
about it. Also, it makes for a somewhat clumsy API as the user is
constantly
This means the generator doesn't have to look at the key, which is a
little nicer - we're pretty close to no key dependencies at all.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_defines.h| 4
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 9 ++---
src/mesa
brw->wm.prog_data is covered by CACHE_NEW_WM_PROG, not
BRW_NEW_FRAGMENT_PROGRAM. So, we should listen to it.
However, I believe that BRW_NEW_FRAGMENT_PROGRAM is sufficient to cover
all the necessary cases - CACHE_NEW_WM_PROG happens in a subset of
cases. So, the code being wrong shouldn't have t
prog_data->foo is a bit more readable than brw->wm.prog_data->foo.
The local variable definition is also a great location to put the
obligatory /* CACHE_NEW_WM_PROG */ comment.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_wm_state.c | 31 +++--
src/mesa/drive
Kristian noted that there's very little use of brw_wm_prog_key in the
generator, and that it basically just generates what it's told, without
caring about what stage it's handling.
One exception to this is derivative handling. When handling dFdxCoarse
and dFdxFine, we packed an enum value in a se
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_wm_state.c | 3 ++-
src/mesa/drivers/dri/i965/gen6_wm_state.c| 2 +-
src/mesa/drivers/dri/i965/gen7_wm_state.c| 2 +-
src/mesa/drivers/dri/i965/gen8_depth_state.c | 4 ++--
src/mesa/drivers/dri/i965/gen8_ps_state.c|
When using MRT on Gen4-5, we have to simulate GL's alpha test feature
by emitting discards in the fragment shader. In this case, it makes
sense to set prog_data->uses_kill, which means the fragment shader may
kill pixels via the discard mechanism.
This saves us from having to look an extra key va
From: Axel Davy
Some queries need the driver to advertise a cap to be supported.
For example r300 doesn't support them.
v2 (David): check also for PIPE_CAP_QUERY_PIPELINE_STATISTICS, fix wine
tests on r300g
Cc: "10.4"
Reviewed-by: David Heidelberg
Signed-off-by: Axel Davy
---
sr
Restores proper immediate tearing swap behaviour for
OpenGL bufferswap under DRI3/Present.
Cc: "10.3 10.4"
Signed-off-by: Mario Kleiner
---
src/glx/dri3_glx.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 5796491..c53be1b
Hi
Here three patches against mesa to fix use of the OML_sync_control
extension under DRI3/Present and restore behaviour compatible to
the DRI2 implementation, so applications like mine, which were written
and tested against DRI2, don't fail miserably under the new backend.
Tested on Intel HD Iro
Prevent calls to glXGetSyncValuesOML() and glXWaitForMscOML()
from overwriting the (ust,msc) values of the last successfull
swapbuffers call (PresentPixmapCompleteNotify event), as
glXWaitForSbcOML() relies on those values corresponding to
the most recent completed swap, not to whatever was last
re
targetSBC == 0 is a special case, which asks the function
to block until all pending OpenGL bufferswap requests have
completed.
Currently the function just falls through for targetSBC == 0,
returning bogus results.
This breaks applications originally written and tested against
DRI2 which also rel
https://bugs.freedesktop.org/show_bug.cgi?id=71199
--- Comment #7 from Roland Scheidegger ---
(In reply to Laura Ekstrand from comment #6)
> I recently ported this test from Glean to Piglit, and I took another look at
> it just now. From my understanding, I think the logic of the test is
> corre
https://bugs.freedesktop.org/show_bug.cgi?id=80848
--- Comment #27 from Emil Velikov ---
Guys if you're still having fun with this can attach the output with the
following patch ? It should make ld a bit more chatty on the topic :)
diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am
index 451
https://bugs.freedesktop.org/show_bug.cgi?id=80848
--- Comment #26 from Emil Velikov ---
Scratch-out comment 25. Seems like I've got a bit confused there :)
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing
On Sun Nov 23 2014 at 2:51:42 AM Marek Olšák wrote:
> A few Gallium queries don't need and it's invalid to call begin_query.
> Those are PIPE_QUERY_GPU_FINISHED (D3DQUERYTYPE_EVENT) and
> PIPE_QUERY_TIMESTAMP (D3DQUERYTYPE_TIMESTAMP).
>
> Right, Axel explained that to me on irc as well.
I didn't
I like the macros Nouveau, and probably other drivers, do lits of token
pasting on all sorts of gallium tokens. I think it makes the code
considerably easier to read.
On Nov 24, 2014 7:07 PM, "Eric Anholt" wrote:
> This made it harder to modify TGSI_OPCODE_ enums without breaking the
> driver
https://bugs.freedesktop.org/show_bug.cgi?id=80848
Emil Velikov changed:
What|Removed |Added
CC||emil.l.veli...@gmail.com
--- Comment #25
---
src/util/u_atomic.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h
index 13b264f..620191c 100644
--- a/src/util/u_atomic.h
+++ b/src/util/u_atomic.h
@@ -9,6 +9,8 @@
#ifndef U_ATOMIC_H
#define U_ATOMIC_H
+#include
+
/*
GCC >= 4.1 support the __sync_* intrinsics. That seems like a
sufficiently old baseline.
---
src/util/u_atomic.h | 122
1 file changed, 122 deletions(-)
diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h
index f326bd1..13b264f 100644
--- a/
like how C11's stdatomic.h provides generic functions. GCC's __sync_*
builtins already take a variety of types, so that's simple.
MSVC and Sun Studio don't, but we can implement it with something that
looks a little crazy but is actually quite readable.
---
src/util/u_atomic.h | 202 +
There was already an intrinsics path that implemented all of the same
functions, plus more.
---
src/util/u_atomic.h | 70 -
1 file changed, 70 deletions(-)
diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h
index 51e799e..f326bd1 100644
---
---
src/util/u_atomic.h | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h
index 8653e73..51e799e 100644
--- a/src/util/u_atomic.h
+++ b/src/util/u_atomic.h
@@ -9,26 +9,23 @@
#ifndef U_ATOMIC_H
#define U_ATOMIC_H
-#incl
---
src/util/u_atomic.h | 58 ++---
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h
index 2500bc7..8653e73 100644
--- a/src/util/u_atomic.h
+++ b/src/util/u_atomic.h
@@ -45,7 +45,7 @@ extern "
I've got some thread-safety fixes queued up after this and thought I'd
be a good Mesa citizen and pull some code into src/util.
I did some clean ups like replacing INLINE (MSVC knows about "inline"
these days, right?) and used stdbool.h instead of the "boolean" type.
I also removed the inline ass
To be shared outside of Gallium.
---
src/gallium/Automake.inc | 2 +
src/gallium/auxiliary/util/u_atomic.h | 401 --
src/util/u_atomic.h | 401 ++
3 files changed, 403 insertions(+), 401 deletions(-)
On Mon, Nov 24, 2014 at 3:06 PM, Jordan Justen
wrote:
> Signed-off-by: Jordan Justen
> ---
> src/glsl/glsl_parser_extras.cpp | 10 +++---
> src/glsl/glsl_parser_extras.h | 2 +-
> src/mesa/main/getstring.c | 6 ++
> 3 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --g
This made it harder to modify TGSI_OPCODE_ enums without breaking the driver.
---
src/gallium/drivers/freedreno/ir3/ir3_compiler.c | 172 ++---
.../drivers/freedreno/ir3/ir3_compiler_old.c | 74 -
2 files changed, 123 insertions(+), 123 deletions(-)
diff --git a/s
This made it harder to modify TGSI_OPCODE_ enums without breaking the driver.
---
.../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 278 ++---
1 file changed, 139 insertions(+), 139 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
b/src/galli
https://bugs.freedesktop.org/show_bug.cgi?id=71199
--- Comment #6 from Laura Ekstrand ---
I recently ported this test from Glean to Piglit, and I took another look at it
just now. From my understanding, I think the logic of the test is correct, but
perhaps you are correct that the implementation
From: Axel Davy
This is the behaviour that wine tests.
Cc: "10.4"
Reviewed-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/query9.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/nine/query9.c
b/src/gall
From: Axel Davy
This is the behaviour that Wine tests
Cc: "10.4"
Tested-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/query9.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/state_trackers/nine/query9.c
b/src/gallium/state_trackers/nin
From: Axel Davy
Issuing D3DISSUE_END should:
. reset previous queries if possible
. end the query
Previous behaviour wasn't calling end_query for
queries not needing D3DISSUE_BEGIN, no resetting
previous queries.
Cc: "10.4"
Tested-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/galliu
From: Axel Davy
It is the same behaviour as wine has.
Cc: "10.4"
Reviewed-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/query9.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/nine/query9.c
b/src/gallium
From: Axel Davy
Nine was allowing that behaviour, but was not filling the result.
Cc: "10.4"
Tested-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/query9.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state
From: Axel Davy
Cc: "10.4"
Tested-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/query9.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/src/gallium/state_trackers/nine/query9.c
b/src/gallium/state_trackers/nine/quer
From: Axel Davy
Some queries need the driver to advertise a cap to be supported.
For example r300 doesn't support them.
Cc: "10.4"
Tested-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/device9.c | 2 +-
src/gallium/state_trackers/nine/query9.c | 43 ++
From: Axel Davy
Applications are supposed to call CreateQuery with a NULL
ppQuery to know if the query is supported. We supported that.
However when ppQuery was not NULL, we were accepting to create the
query and were creating a dummy query even when the query is not
supported.
Wine has differe
From: Axel Davy
Cc: "10.4"
Reviewed-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/query9.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/nine/query9.c
b/src/gallium/state_trackers/nine/query9.c
index 7
From: Axel Davy
It is an sint_4, but it was stored in a uint_8...
The code using it was acting as if it was signed.
Problem found thanks to Coverity
Cc: "10.4"
Tested-by: David Heidelberg
Reviewed-by: Ilia Mirkin
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/nine_shader.c |
From: Axel Davy
Error detected by Coverity (COPY_PASTE_ERROR)
Cc: "10.4"
Reviewed-by: Ilia Mirkin
Signed-off-by: Axel Davy
Signed-off-by: David Heidelberg
---
src/gallium/state_trackers/nine/nine_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_t
2efabd9f5a711a7f6cd1846630244b7814bf25b3 removed them as unused.
This caused random memory overwrites (reported by Coverity).
Cc: "10.4"
Reviewed-by: Ilia Mirkin
Reviewed-by: Marek Olšák
Reviewed-by: Axel Davy
Signed-off-by: David Heidelberg
---
src/gallium/state_trackers/nine/nine_state.c
PIPE_CAP_VIDEO_MEMORY returns the amount of video memory in megabytes,
so need to converted it to bytes.
Fixed Warframe memory detection.
v2: also prepare for cards with more than 4GB memory
Cc: "10.4"
Tested-by: Yaroslav Andrusyak
Reviewed-by: Ilia Mirkin
Reviewed-by: Axel Davy
Signed-off-b
From: Axel Davy
This patch moves the data field from Resource9 to Surface9 and cleans
D3DPOOL_SYSTEMMEM handling in Texture9. This fixes HL2 lost coast.
It also removes in Texture9 some code written to support importing
and exporting non D3DPOOL_SYSTEMMEM shared buffers. This code hadn't
the des
From: Axel Davy
D3DPOOL_SCRATCH is disallowed according to spec.
D3DPOOL_SYSTEMMEM should be allowed but we don't handle it right for now.
v2: Fixes segfault in SetTexture when unsetting the texture
Cc: "10.4"
Tested-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_tracke
From: Stanislaw Halik
Cc: "10.4"
Reviewed-by: Ilia Mirkin
Reviewed-by: David Heidelberg
Reviewed-by: Axel Davy
Signed-off-by: Stanislaw Halik
---
src/gallium/state_trackers/nine/basetexture9.c | 17
src/gallium/state_trackers/nine/cubetexture9.c | 17
src/gallium/s
From: Axel Davy
Fixes "Error : CONST[20]: Undeclared source register" when running
dx9_alpha_blending_material. Also artifacts on ilo.
v2: also remove unused MISC_CONST
Cc: "10.4"
Tested-by: David Heidelberg
Reviewed-by: Ilia Mirkin
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/n
From: Axel Davy
Instead of having parts of the structures initialised by the parents,
have them initialised by the children.
Cc: "10.4"
Tested-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/basetexture9.c | 19 +++
src/gallium/state_tracke
From: Axel Davy
Pass ex specific parameters as arguments to device9 ctor instead
of passing them by filling the structure.
Cc: "10.4"
Reviewed-by: David Heidelberg
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/nine/adapter9.c | 2 +-
src/gallium/state_trackers/nine/device9.c |
Signed-off-by: Jordan Justen
---
src/glsl/glsl_parser_extras.cpp | 10 +++---
src/glsl/glsl_parser_extras.h | 2 +-
src/mesa/main/getstring.c | 6 ++
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
Reviewed-by: Jose Fonseca
Jose
On 24/11/14 22:37, srol...@vmware.com wrote:
From: Roland Scheidegger
llvmpipe disables denorms on purpose (on x86/sse only), because denorms are
generally neither required nor desired for graphic apis (and in case of d3d10,
they are forbidden).
However, this c
From: Roland Scheidegger
llvmpipe disables denorms on purpose (on x86/sse only), because denorms are
generally neither required nor desired for graphic apis (and in case of d3d10,
they are forbidden).
However, this caused some arithmetic tests using denorms to fail on some
systems, because the re
https://bugs.freedesktop.org/show_bug.cgi?id=71199
--- Comment #5 from Roland Scheidegger ---
(In reply to José Fonseca from comment #4)
> This test was renamed, but the issue is still there:
>
> $ ./bin/gl-1.4-polygon-offset -auto
> Actual MRD is too small (may cause incorrect results)
>
https://bugs.freedesktop.org/show_bug.cgi?id=55343
José Fonseca changed:
What|Removed |Added
CC||jfons...@vmware.com
Summary|[l
Partially fixes broken rendering in Windows-based QtQuick2 apps run through
Wine.
This library sets all texture units' GL_COORD_REPLACE, leaves point
sprite mode enabled, and then draws a triangle fan.
Will need a slightly different fix for Gen4-5, but I don't have my old
machines in a usable sta
Axel Davy writes:
> Hi,
>
> Series looks good. You can add my r-b.
>
> Do you want also to remove the DP2A reference like
> did Jose patch ?
The rest of my series doesn't touch DP2A, so I wasn't planning on it.
pgpq8Vu6pmNT9.pgp
Description: PGP signature
__
Oops -- this is what I get for dropping that comment in at the last
minute while reviewing the mail and forgetting to adjust the header.
Will resend.
On Tue, Nov 25, 2014 at 9:22 AM, Ilia Mirkin wrote:
> On Mon, Nov 24, 2014 at 2:33 PM, Chris Forbes wrote:
>> Partially fixes broken rendering in
https://bugs.freedesktop.org/show_bug.cgi?id=78914
José Fonseca changed:
What|Removed |Added
Summary|[llvmpipe] Front/Backfaces |[llvmpipe] Front/Backfaces
On Mon, Nov 24, 2014 at 2:33 PM, Chris Forbes wrote:
> Partially fixes broken rendering in Windows-based QtQuick2 apps run through
> Wine.
> This library sets all texture units' GL_COORD_REPLACE, leaves point
> sprite mode enabled, and then draws a triangle fan.
>
> Will need a slightly different
https://bugs.freedesktop.org/show_bug.cgi?id=71199
José Fonseca changed:
What|Removed |Added
Summary|[llvmpipe] piglit glean |[llvmpipe] piglit
|poly
https://bugs.freedesktop.org/show_bug.cgi?id=67672
José Fonseca changed:
What|Removed |Added
CC||jfons...@vmware.com
Assignee|me
Partially fixes broken rendering in Windows-based QtQuick2 apps run through
Wine.
This library sets all texture units' GL_COORD_REPLACE, leaves point
sprite mode enabled, and then draws a triangle fan.
Will need a slightly different fix for Gen4-5, but I don't have my old
machines in a usable sta
On Mon, Nov 24, 2014 at 2:13 AM, Samuel Iglesias Gonsálvez
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
> I found a GLSL ES test that provides an invalid argument to #pragma
> debug() such as:
>
> #pragma debug (1.23)
>
> And it expects a compilation error. Mesa doesn'
On 24/11/2014 06:54, Ilia Mirkin wrote :
On Sun, Nov 23, 2014 at 5:40 PM, David Heidelberg wrote:
From: Axel Davy
Fixes "Error : CONST[20]: Undeclared source register" when running
dx9_alpha_blending_material. Also artifacts on ilo.
Cc: "10.4"
Tested-by: David Heidelberg
Signed-off-by: Axe
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Thanks Ken. These look good, and they let the new shader-db runner
compile fp/vp programs! The series is
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, Nov 24, 2014 at 12:28 AM, Kenneth Graunke wrote:
> We already precompile GLSL programs; it seems logical to precompile ARB
> programs as well. We just never hooked it up.
>
> This also makes the programs compile even if no drawing occurs, which is
> useful for shader-db.
>
> Signed-off-by
On Mon, Nov 24, 2014 at 12:28 AM, Kenneth Graunke wrote:
> Previously, the prototypes for brw_vs/gs/fs_precompile were scattered
> between brw_vs.h (C), brw_gs.h (C), and brw_fs.h (C++ only). Also,
> brw_fs_precompile had C++ linkage, while the others were C.
>
> This patch moves all the prototyp
On Mon, Nov 24, 2014 at 12:28 AM, Kenneth Graunke wrote:
> We'd like to do precompiling for ARB vertex and fragment programs,
> which only have gl_program structures - gl_shader_program is NULL.
>
> This patch makes the various precompile functions take a gl_program
> parameter directly, rather th
On Mon, Nov 24, 2014 at 12:28 AM, Kenneth Graunke wrote:
> brw_shader_precompile should just do a precompile; it makes more sense
> for the caller to decide whether we should do one. Simpler.
That makes a lot more sense,
Reviewed-by: Kristian Høgsberg
> Signed-off-by: Kenneth Graunke
> ---
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I found a GLSL ES test that provides an invalid argument to #pragma
debug() such as:
#pragma debug (1.23)
And it expects a compilation error. Mesa doesn't complain about it,
just ignore the whole thing. The allowed keywords are 'on' and '
On 24/11/14 08:53, Kenneth Graunke wrote:
On Monday, November 24, 2014 09:44:38 PM Chris Forbes wrote:
This was just returning the same value as GL_CURRENT_MATRIX_ARB.
Spotted while investigating something else in apitrace.
Signed-off-by: Chris Forbes
Cc: "10.3 10.4"
---
src/mesa/main/get_h
On Thu, 2014-11-20 at 09:33 -0800, Ian Romanick wrote:
> On 11/20/2014 05:33 AM, Neil Roberts wrote:
> > For what it's worth, I did a quick grep through the internal and public
> > shader-db and I couldn't find anything using this.
> >
> > git grep -P '\b(? >
> > If AMD disallows it then it seem
On Monday, November 24, 2014 09:44:38 PM Chris Forbes wrote:
> This was just returning the same value as GL_CURRENT_MATRIX_ARB.
> Spotted while investigating something else in apitrace.
>
> Signed-off-by: Chris Forbes
> Cc: "10.3 10.4"
> ---
> src/mesa/main/get_hash_params.py | 2 +-
> 1 file c
This was just returning the same value as GL_CURRENT_MATRIX_ARB.
Spotted while investigating something else in apitrace.
Signed-off-by: Chris Forbes
Cc: "10.3 10.4"
---
src/mesa/main/get_hash_params.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/get_hash_pa
We already precompile GLSL programs; it seems logical to precompile ARB
programs as well. We just never hooked it up.
This also makes the programs compile even if no drawing occurs, which is
useful for shader-db.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_program.c | 11 +
brw_shader_precompile should just do a precompile; it makes more sense
for the caller to decide whether we should do one. Simpler.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/dri
Previously, the prototypes for brw_vs/gs/fs_precompile were scattered
between brw_vs.h (C), brw_gs.h (C), and brw_fs.h (C++ only). Also,
brw_fs_precompile had C++ linkage, while the others were C.
This patch moves all the prototypes to a central location (brw_shader.h)
and makes brw_fs_precompile
We'd like to do precompiling for ARB vertex and fragment programs,
which only have gl_program structures - gl_shader_program is NULL.
This patch makes the various precompile functions take a gl_program
parameter directly, rather than accessing it via gl_shader_program.
Signed-off-by: Kenneth Grau
83 matches
Mail list logo
