https://bugs.freedesktop.org/show_bug.cgi?id=28071
Summary: undefined reference to `__egl InitDriverFallbacks'
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Cygwin
Status: NEW
Severity: critical
Priori
On Tue, 2010-05-11 at 07:45 -0700, Marek Olšák wrote:
> On Tue, May 11, 2010 at 12:49 PM, José Fonseca
> wrote:
> Attached is my proposal for fine grained caps for shader
> limits.
>
> I'd like have a cap for MaxNativeAluInstructions too. ;) Otherwise it
> looks good.
OK. Sounds
2010/5/11 Brian Paul :
> Kristian Høgsberg wrote:
>>
>> 2010/5/6 Kristian Høgsberg :
>>>
>>> Hi,
>>>
>>> Ok, I suppose this is not the most pressing issue in mesa, but I was
>>> toying with an idea of how to reduce get.c size and integrate
>>> get_es1.c and get_es2.c and I had to try it out. Of co
I have been testing the peephole optimizer from Nicolai's r300g-glsl
branch. There is a bug in it that breaks two of the piglit test cases:
glsl-fs-fragcoord and glsl-orangebook-ch06-bump. Here is an example of
the bug from glsl-fs-fragcoord:
0: RCP temp[3].w, input[0].w___;
1: MUL temp[3].xy, i
Kristian Høgsberg wrote:
2010/5/6 Kristian Høgsberg :
Hi,
Ok, I suppose this is not the most pressing issue in mesa, but I was
toying with an idea of how to reduce get.c size and integrate
get_es1.c and get_es2.c and I had to try it out. Of course it ended
up being a bigger project and took a
On Tue, May 11, 2010 at 12:49 PM, José Fonseca wrote:
> Attached is my proposal for fine grained caps for shader limits.
>
I'd like have a cap for MaxNativeAluInstructions too. ;) Otherwise it looks
good.
On Tue, May 11, 2010 at 3:53 PM, José Fonseca wrote:
> Hardware tends to follow these sh
On Tue, 2010-05-11 at 06:38 -0700, Jakob Bornecrantz wrote:
> On 2010-05-11 11.49, José Fonseca wrote:
> > Attached is my proposal for fine grained caps for shader limits.
> >
> > These don't cover which opcodes are supported, so PIPE_CAP_GLSL and
> > PIPE_CAP_SM3 remains. I think that PIPE_CAP_SM3
Dan Nicholson writes:
> On Mon, May 10, 2010 at 6:54 PM, tom fogal wrote:
> > Dan Nicholson writes:
> >> On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs wrote:
> >> > All I really want is Mesa with OSMesa from the development
> >> > repository as the "reference" library for my VTK and ParaView
On 2010-05-11 11.49, José Fonseca wrote:
Attached is my proposal for fine grained caps for shader limits.
These don't cover which opcodes are supported, so PIPE_CAP_GLSL and
PIPE_CAP_SM3 remains. I think that PIPE_CAP_SM3 should be rename to
PIPE_CAP_SM, which shader model major/minor version en
On 05/10/2010 04:48 PM, Dan Nicholson wrote:
> On Mon, May 10, 2010 at 12:51 PM, Kevin H. Hobbs wrote:
>> The mesa/configs/linux-x86-64 target makes this symbol global while the
>> auto tools configuration makes this symbol local...
>
> I guess this is because configure adds -fvisibility=hidden t
On Mon, May 10, 2010 at 6:54 PM, tom fogal wrote:
> Dan Nicholson writes:
>> On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs wrote:
>> > All I really want is Mesa with OSMesa from the development
>> > repository as the "reference" library for my VTK and ParaView
>> > nightly test builds.
>>
>>
Attached is my proposal for fine grained caps for shader limits.
These don't cover which opcodes are supported, so PIPE_CAP_GLSL and
PIPE_CAP_SM3 remains. I think that PIPE_CAP_SM3 should be rename to
PIPE_CAP_SM, which shader model major/minor version encoded in a dword.
PIPE_CAP_GLSL could proba
On Sun, 2010-04-25 at 09:50 -0700, José Fonseca wrote:
> Now that transfers are context operations it is the driver's
> responsibility to ensure that transfers happen in order with all other
> context operations, so flushes and finishes inside Mesa should be no
> longer necessary. The attached patc
13 matches
Mail list logo
