On Sun, 2010-01-24 at 18:36 -0800, Igor Oliveira wrote:
> The patch fixes the bug 25863.
> The bug happens when i use blend types like multiply, screen, dark in
> vega state tracker.
>
> --- a/src/gallium/drivers/softpipe/sp_state_sampler.c
> +++ b/src/gallium/drivers/softpipe/sp_state_sampler.c
>
mesa_7_7_branch and master are becoming quite different, because of all
the gallium interface changes that have been going into master, so
merging fixes from mesa_7_7_branch into master is becoming less and less
of a trivial exercise.
This is aggravated by the fact we are basing a release from the
On Sat, 2010-01-23 at 01:33 -0800, Sorin Popescu wrote:
> It almost builds now but there's still a bit of a screwup in
> vmw_screen_pools.c, fenced_bufmgr_create is gone. The debug code below
> it works fine though. Also, pb_buffer_fenced.c is missing from
> auxilliary/Makefile. Sorry I can't be mo
Brian Paul wrote on 2010-01-22 17:56:
> michal wrote:
>
>> Brian Paul wrote on 2010-01-21 21:57:
>>
>>> michal wrote:
>>>
>>>
Hi,
This simple feature branch adds support for two-dimensional constant
buffers in TGSI.
An example shader would look like
I would like to have those two modules go away, as they are maintenance
pain with no real benefits.
The build module has been superseded by the ureg module, and apparently
all third-party code has already migrated or is in the process of
porting to new interface. I would like to nuke it if nobo
Michal,
On Mon, 2010-01-25 at 06:27 -0800, michal wrote:
> I would like to have those two modules go away, as they are maintenance
> pain with no real benefits.
>
> The build module has been superseded by the ureg module, and apparently
> all third-party code has already migrated or is in the p
José Fonseca wrote:
> Michal,
>
> On Mon, 2010-01-25 at 06:27 -0800, michal wrote:
>> I would like to have those two modules go away, as they are maintenance
>> pain with no real benefits.
>>
>> The build module has been superseded by the ureg module, and apparently
>> all third-party code has a
Hi Jakob,
On Wed, Jan 20, 2010 at 12:20 PM, Chia-I Wu wrote:
> On Sun, Jan 17, 2010 at 10:24 AM, Chia-I Wu wrote:
>> I myself would like to see the st_visual and st_api->make_current issues
>> resolved (listed as issue 1 and 3 in DESIGN file).
> The DESIGN file is available at
> http://cgit.free
Luca Barbieri wrote:
>> Signed-off-by: Brian Paul
> Please push this as well.
Done.
-Brian
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating o
Hi,
You are right!. The bug happens in blend_bind_samplers in shader.c the
texture[0] is NULL and it is wrong initialized.
The patch below fix it:
--- a/src/gallium/state_trackers/vega/shader.c
+++ b/src/gallium/state_trackers/vega/shader.c
@@ -135,8 +135,8 @@ static VGint blend_bind_samplers(s
Looks good. I'll commit this.
-Brian
Igor Oliveira wrote:
> Hi,
>
> You are right!. The bug happens in blend_bind_samplers in shader.c the
> texture[0] is NULL and it is wrong initialized.
>
> The patch below fix it:
>
>
> --- a/src/gallium/state_trackers/vega/shader.c
> +++ b/src/gallium/st
http://bugs.freedesktop.org/show_bug.cgi?id=25863
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Brian Paul wrote on 2010-01-25 16:09:
> José Fonseca wrote:
>
>> Michal,
>>
>> On Mon, 2010-01-25 at 06:27 -0800, michal wrote:
>>
>>> I would like to have those two modules go away, as they are maintenance
>>> pain with no real benefits.
>>>
>>> The build module has been superseded by the
Hi guys,
It would be very important that your small Gallium communitycould be larger if
you develop some Documentation. So far,newbies in this area hardly could enter
into your projecteven if we want to do it on a voluntary basis.
I really want to contribute but please provide us at leastmore th
writes:
[snip]
> The ideal would be to peer-review the merges before committing,
> but it seems difficult to do that with git, while preserving merge
> history and not redoing merges.
Google has developed an infrastructure to do peer review using git.
`Gerrit':
http://code.google.com/p/gerrit/
http://bugs.freedesktop.org/show_bug.cgi?id=26224
Summary: [GLSL] Cannot get location of a uniform struct member
Product: Mesa
Version: 7.6
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
On Mon, 2010-01-25 at 09:52 -0800, tom fogal wrote:
> writes:
> [snip]
> > The ideal would be to peer-review the merges before committing,
> > but it seems difficult to do that with git, while preserving merge
> > history and not redoing merges.
>
> Google has developed an infrastructure to do pee
I think we've touched on a core git workflow issue here, and its likely
others have hit this && have a solution, so I've added the git ML to
the CC list.
Git: the situation in this repo is a fast-moving master that is
including many changes to internal interfaces. Stable branches just
get bugfixe
On Mon, 25 Jan 2010 13:04:10 +, José Fonseca wrote:
> mesa_7_7_branch and master are becoming quite different, because of all
> the gallium interface changes that have been going into master, so
> merging fixes from mesa_7_7_branch into master is becoming less and less
> of a trivial exercise.
On Mon, Jan 25, 2010 at 12:17 PM, Eric Anholt wrote:
> On Mon, 25 Jan 2010 13:04:10 +, José Fonseca wrote:
>> mesa_7_7_branch and master are becoming quite different, because of all
>> the gallium interface changes that have been going into master, so
>> merging fixes from mesa_7_7_branch int
Alex Deucher wrote:
> On Mon, Jan 25, 2010 at 12:17 PM, Eric Anholt wrote:
>> On Mon, 25 Jan 2010 13:04:10 +, José Fonseca wrote:
>>> mesa_7_7_branch and master are becoming quite different, because of all
>>> the gallium interface changes that have been going into master, so
>>> merging fixe
Uros,
Next time, please start a new discussion with a new subject instead of
hijacking an unrelated thread. Thanks.
Anyway, we're writing more detailed gallium docs under
src/gallium/docs/ Have you seen those?
Also bear in mind that we're probably not going to write docs
specifically target
On Mon, 2010-01-25 at 12:31 -0800, Brian Paul wrote:
> Alex Deucher wrote:
> > On Mon, Jan 25, 2010 at 12:17 PM, Eric Anholt wrote:
> >> On Mon, 25 Jan 2010 13:04:10 +, José Fonseca
> >> wrote:
> >>> mesa_7_7_branch and master are becoming quite different, because of all
> >>> the gallium in
José Fonseca wrote:
> On Mon, 2010-01-25 at 12:31 -0800, Brian Paul wrote:
>> Alex Deucher wrote:
>>> On Mon, Jan 25, 2010 at 12:17 PM, Eric Anholt wrote:
On Mon, 25 Jan 2010 13:04:10 +, José Fonseca
wrote:
> mesa_7_7_branch and master are becoming quite different, because of a
I've been targeting an audience of people that have taken some CS,
read some Wikipedia, but aren't experienced with 3D graphics. I'd kind
of like it if people would go read a Red Book, even the out-of-date
one available free online, before diving in... If you don't know C,
then the docs won't teach
Hello,
This is just a report about the work i am doing.
2 days ago i began to study the vega state tracker to understand
better and help a bit since there i already fix some bugs.
So right now i am implementing the advanced blending extension[1].
This extension include many blending methods suppo
Hi michal,
you could me maintain informed about that changes? i am creating my
environment to try to create tgsi neon optimizations. I am using
beagleboard + Angstrom distribution in my environment. And i thinking
something about dsp too.
Igor
On Mon, Jan 25, 2010 at 1:02 PM, michal wrote:
> Br
On Monday 25 January 2010 16:38:46 Igor Oliveira wrote:
> Hello,
>
> This is just a report about the work i am doing.
>
> 2 days ago i began to study the vega state tracker to understand
> better and help a bit since there i already fix some bugs.
> So right now i am implementing the advanced ble
Hello
On Mon, Jan 25, 2010 at 5:51 PM, Zack Rusin wrote:
> On Monday 25 January 2010 16:38:46 Igor Oliveira wrote:
>> Hello,
>>
>> This is just a report about the work i am doing.
>>
>> 2 days ago i began to study the vega state tracker to understand
>> better and help a bit since there i already
http://bugs.freedesktop.org/show_bug.cgi?id=26230
Summary: Create developer account
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: Mesa c
Hello
this patch applies in double-opcode-branch.
It adds documentation to double opcodes.
Igor
From 135fd9c851e9b50149508a3e7c04203623cc297b Mon Sep 17 00:00:00 2001
From: Igor Oliveira
Date: Mon, 25 Jan 2010 19:23:04 -0400
Subject: [PATCH] docs: add documentation to double opcodes
---
src/ga
Marc Dietrich wrote:
> this is needed at least for gcc. dunno about the other compilers.
> ---
> src/gallium/include/pipe/p_compiler.h |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/include/pipe/p_compiler.h
> b/src/gallium/include/pipe/p_compiler.
Marc,
Why is this necessary? It has been working fine so far. Which gcc version are
you using? What commas are you referring to?
Variadic macros aren't portable. This change would break MSVC build.
It seems that there is some code that's trying to pass more than 2 args to
PIPE_ALIGN_TYPE. That
On Fri, Jan 22, 2010 at 10:31 AM, Chia-I Wu wrote:
> On Thu, Jan 21, 2010 at 9:53 PM, Dan Nicholson wrote:
>> On Thu, Jan 21, 2010 at 2:29 AM, Chia-I Wu wrote:
>>> This is one of the changes I want to do for a while. GLX was built
>>> specially
>>> and before Mesa core because libglapi.a could
I think instead of targeting newbies, it would be preferable to have a
proper API documentation first. We're severely lacking in the "what
flags go here" department, and generally it would be nice to have a key
that explains exactly what each argument for each function is. It's
normally not too har
First of all I consider myself as experienced C/C++/Java programmer.Even tough
I know other languages this is my primary area of expertise.Also I have very
good background in CS, mathematics, etc.
What I wanted to say is that rapidly-changing GPU architectures marketis not
possible to track if
>
> Another thing that bother me, is that gallium community is very small
> but worse thing is that some of people who are working on gallium are
> very hard to approach, even arrogant. This is certainly not way how to
> build successful society, for sure. It looks like that they consider
> thems
37 matches
Mail list logo
