From: Christopher James Halse Rogers
---
src/gallium/drivers/r300/r300_screen.c| 8 ++-
src/gallium/drivers/r300/r300_texture.c | 2 +-
src/gallium/drivers/r600/r600_pipe.c | 7 ++-
src/gallium/drivers/r600/r600_texture.c | 2 +-
src/gallium/drive
From: Christopher James Halse Rogers
It's a map of GEM name->bo, so identify it as such
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeo
From: Christopher James Halse Rogers
---
src/gallium/drivers/nouveau/nouveau_screen.c | 19 ++-
src/gallium/drivers/nouveau/nouveau_screen.h | 2 ++
src/gallium/drivers/nv30/nv30_screen.c | 6 +-
src/gallium/drivers/nv50/nv50_screen.c | 5 -
src/gallium/dri
From: Christopher James Halse Rogers
This is only exposed by drivers wich support the new PIPE_CAP_PRIME parameter,
for PRIME import/export.
---
This stubs out texture_from_renderbuffer, which I don't care about, but
that looks like it wouldn't be terribly painful to implement if it's a blocker
Hi all,
On Monday, April 22, 2013 00:39:57 Tom Stellard wrote:
[...]
The only pro for further investigating the dlopen flags is that I fear the
distribution builders who invented dynamic linking in the drivers. That change
destroyed symbol isolation in the drivers at that point. They will prob
On Sat, Apr 20, 2013 at 02:20:23PM +0200, Christian König wrote:
> Am 20.04.2013 09:27, schrieb Mathias Fröhlich:
> > Hi Tom,
> >
> > May be I need to tell where the problem really appears in real life.
> > OpenSceneGraph has some nifty features regarding multi channel rendering.
> > Assume a setup
Hello,
I am really interested in doing the GSOC 2013 project "Find common patterns
in real GLSL shaders".
Implementation:
Algorithm:- Max-miner algorithm as it uses the same data structure as
Apriori i.e. hash tree.
The following implementation has been found faster than normal ways:
Max-Miner us
Hi,
My name is Sida Li and I am a senior student from Peking University in China. I
am interested in the idea that improved application of GLSL complier
optimizations.
I have downloaded the source code and read some parts of the it. First let me
talk about my understanding about the problem.
This puts a global pipe_context in r600_screen, which is guarded by a mutex,
so that we can use pipe_context when there isn't one around.
Hopefully our multi-context support is solid.
---
src/gallium/drivers/r600/r600_blit.c| 31
src/gallium/drivers/r600/r600_pipe.c
Although this might be useful for ARB_clear_buffer_object,
I need it for initializating resources in r600g.
---
src/gallium/auxiliary/util/u_blitter.c | 81 +---
src/gallium/auxiliary/util/u_blitter.h | 18 ++-
2 files changed, 91 insertions(+), 8 deletions(-)
Initial work on the implementation of GL_ARB_shading_language_420pack.
The patch adds the functionality from this extension which allows
for C-style array initialization for GLSL. The extension enable bits
and extension definition are also included in this patch.
---
src/glsl/ast.h
Yeah, I was confused when reading the comment and the diagrams. It
probably shouldn't mention the screen origin at all and instead should
say which one of the top and bottom edges is inclusive and which one
is exclusive when determining pixel ownership.
Anyway, thank you for fixing this. I would h
https://bugs.freedesktop.org/show_bug.cgi?id=26663
--- Comment #3 from Sérgio M. Basto ---
--enable-glx-tls breaks glxinfo of nvidia property drives on Fedora 19 Alfa .
--
You are receiving this mail because:
You are the assignee for the bug.
___
me
https://bugs.freedesktop.org/show_bug.cgi?id=26663
Sérgio M. Basto changed:
What|Removed |Added
CC||ser...@serjux.com
See Also|
https://bugs.freedesktop.org/show_bug.cgi?id=26663
Sérgio M. Basto changed:
What|Removed |Added
See Also||https://bugzilla.redhat.com
Cc: Brian Paul
---
docs/license.html | 7 ---
src/mapi/glapi/gen/mesadef.py | 7 ---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/docs/license.html b/docs/license.html
index d872cad..80bb604 100644
--- a/docs/license.html
+++ b/docs/license.html
@@ -75,9 +75,
The previous commit introduced extra words, breaking the formatting.
This text transformation was done automatically via the following shell
command:
$ git grep 'THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
OR OTHER LIABILITY' | sed 's/:.*$//' | xargs -I {} sh -c 'vim -e -s {
See previous commit for the rationale. These weren't caught by the
automatic conversion due to the "OR IBM" addition.
Cc: Brian Paul
---
src/mesa/main/arrayobj.c | 2 +-
src/mesa/main/arrayobj.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/arrayobj.c b/sr
I was reviewing some patches and saw more new files that said "IN NO EVENT
SHALL BRIAN PAUL BE LIABLE" but were...not authored by Brian. People
keep doing that by accident, and a lot of those files have been altered
by other people by now anyway.
This series does the sed job to replace "BRIAN PAU
On 04/19/2013 12:35 PM, Jordan Justen wrote:
Signed-off-by: Jordan Justen
---
src/glsl/ast_to_hir.cpp |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Reviewed-by: Kenneth Graunke
___
mesa-dev mailing list
mesa-dev@lists.freedesktop
On 04/19/2013 12:35 PM, Jordan Justen wrote:
For interface blocks, there are three separate namespaces for
uniform, input and output blocks.
http://knowyourmeme.com/photos/2109
There are?
Similarly, for your next patch:
"Uniform/interface blocks are a separate namespace from types."
They are
Kenneth Graunke writes:
> On 04/19/2013 11:35 AM, Eric Anholt wrote:
>> I noticed a fallback in regnum through sysprof, and wanted a nicer way to
>> get information about it.
>> ---
>> src/mesa/drivers/common/meta.c | 28 +---
>> src/mesa/main/errors.h | 10
On 04/19/2013 12:35 PM, Jordan Justen wrote:
Previously uniform blocks allowed for the 'uniform' keyword
to be used with members of a uniform blocks. With interface
blocks 'in' can be used on 'in' interface block members and
'out' can be used on 'out' interface block members.
The basic_interface
On 04/19/2013 12:35 PM, Jordan Justen wrote:
An interface block member may specify the type:
in {
in vec4 in_var_with_qualifier;
};
When specified with the member, it must match the same
type as interface block type.
It can also omit the qualifier:
uniform {
vec4 uniform_var_without_q
On 04/21/2013 04:04 AM, Marek Olšák wrote:
Ah, I didn't know you had any other env vars. It's preferable to have
as many boolean flags as possible handled by a single env var, because
it's easier to use (R600_DUMP_SHADERS counts as a pretty ugly list of
boolean flags hidden behind a magic number)
On 04/19/2013 12:35 PM, Jordan Justen wrote:
Previously only 'uniform' was allowed for uniform blocks.
Now, in/out can be parsed, but it will only be allowed for
GLSL >= 150.
Signed-off-by: Jordan Justen
Reviewed-by: Eric Anholt
Patch 3 is:
Reviewed-by: Kenneth Graunke
- Original Message -
> Some suggestions for the name:
>
> lower_left_edge_rule
> lower_left_rasterization_edge_rule
> gl_edge_rule
> gl_rasterization_edge_rule
>
> In this case, the name is not as important as the documentation which
> defines the behavior of the state.
On that note, I t
On 04/21/2013 12:19 AM, Matt Turner wrote:
Listed in the restrictions section of CMP, but not on the work-arounds
page.
---
src/mesa/drivers/dri/i965/brw_eu_emit.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/d
Some suggestions for the name:
lower_left_edge_rule
lower_left_rasterization_edge_rule
gl_edge_rule
gl_rasterization_edge_rule
In this case, the name is not as important as the documentation which
defines the behavior of the state.
Marek
On Sun, Apr 21, 2013 at 3:56 PM, Jose Fonseca wrote:
> -
- Original Message -
> - Original Message -
> > I have managed to make the triangle-rasterization test pass. Let's
> > forget about what the origin is, because it's not really important.
> > What is actually important is what happens when an edge falls exactly
> > on a sample poin
- Original Message -
> I have managed to make the triangle-rasterization test pass. Let's
> forget about what the origin is, because it's not really important.
> What is actually important is what happens when an edge falls exactly
> on a sample point. Radeons have a state which determines
I have managed to make the triangle-rasterization test pass. Let's
forget about what the origin is, because it's not really important.
What is actually important is what happens when an edge falls exactly
on a sample point. Radeons have a state which determines what happens
for the left, right, top
- Original Message -
> On 21.04.2013 13:18, Jose Fonseca wrote:
> >
> > - Original Message -
> >> On 21.04.2013 09:36, Jose Fonseca wrote:
> >>> - Original Message -
> Do we really need the lower_left_origin state? I think I can't
> implement it for radeon and it
On 21.04.2013 13:18, Jose Fonseca wrote:
>
> - Original Message -
>> On 21.04.2013 09:36, Jose Fonseca wrote:
>>> - Original Message -
Do we really need the lower_left_origin state? I think I can't
implement it for radeon and it's the kind of stuff that should be
take
There are also patches 2, 3, and 4 which you didn't review (3,4) or
didn't agree with (2).
Marek
On Wed, Apr 17, 2013 at 8:30 PM, Eric Anholt wrote:
> Marek Olšák writes:
>
>> _NEW_TRANSFORM_FEEDBACK is not used by core Mesa, so it can be removed.
>> Instead, an new private flag is added to i96
- Original Message -
> On 21.04.2013 12:34, Dave Airlie wrote:
> > On Sun, Apr 21, 2013 at 5:36 PM, Jose Fonseca wrote:
> >> - Original Message -
> >>> Do we really need the lower_left_origin state? I think I can't
> >>> implement it for radeon and it's the kind of stuff that sho
- Original Message -
> Same as Dave. The first one fails, the second one (-use_fbo) passes.
>
> I just hope lower_left_origin doesn't affect the Y axis of the
> viewport, scissor and gl_FragCoord. If it does, a PIPE_CAP would be
> useful to keep the current behavior.
Maybe I'm not expla
- Original Message -
> On 21.04.2013 09:36, Jose Fonseca wrote:
> > - Original Message -
> >> Do we really need the lower_left_origin state? I think I can't
> >> implement it for radeon and it's the kind of stuff that should be
> >> taken care of by the state tracker anyway.
> > M
Same as Dave. The first one fails, the second one (-use_fbo) passes.
I just hope lower_left_origin doesn't affect the Y axis of the
viewport, scissor and gl_FragCoord. If it does, a PIPE_CAP would be
useful to keep the current behavior.
Marek
On Sun, Apr 21, 2013 at 9:36 AM, Jose Fonseca wrote:
On 21.04.2013 12:34, Dave Airlie wrote:
> On Sun, Apr 21, 2013 at 5:36 PM, Jose Fonseca wrote:
>> - Original Message -
>>> Do we really need the lower_left_origin state? I think I can't
>>> implement it for radeon and it's the kind of stuff that should be
>>> taken care of by the state tra
On Sun, Apr 21, 2013 at 5:36 PM, Jose Fonseca wrote:
> - Original Message -
>> Do we really need the lower_left_origin state? I think I can't
>> implement it for radeon and it's the kind of stuff that should be
>> taken care of by the state tracker anyway.
>
> My understanding is that hard
On 21.04.2013 09:36, Jose Fonseca wrote:
> - Original Message -
>> Do we really need the lower_left_origin state? I think I can't
>> implement it for radeon and it's the kind of stuff that should be
>> taken care of by the state tracker anyway.
> My understanding is that hardware had switc
- Original Message -
> - Original Message -
> > Do we really need the lower_left_origin state? I think I can't
> > implement it for radeon and it's the kind of stuff that should be
> > taken care of by the state tracker anyway.
>
> My understanding is that hardware had switches f
- Original Message -
> Do we really need the lower_left_origin state? I think I can't
> implement it for radeon and it's the kind of stuff that should be
> taken care of by the state tracker anyway.
My understanding is that hardware had switches for this sort of thing. It's
really hard t
Listed in the restrictions section of CMP, but not on the work-arounds
page.
---
src/mesa/drivers/dri/i965/brw_eu_emit.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 704f219..f3
On 04/20/2013 07:21 PM, Matt Turner wrote:
Probably a copy-n-paste mistake.
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
Reviewed-by: Kenneth Graunke
___
mesa-dev
46 matches
Mail list logo
