https://bugs.freedesktop.org/show_bug.cgi?id=29044
Gordon Jin changed:
What|Removed |Added
Depends on||29524
--
Configure bugmail: https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Gordon Jin changed:
What|Removed |Added
Depends on||29500
--
Configure bugmail: https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Gordon Jin changed:
What|Removed |Added
Depends on||29498
--
Configure bugmail: https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Gordon Jin changed:
What|Removed |Added
Depends on||29496
--
Configure bugmail: https://bugs.f
Committed, thanks.
-Marek
On Thu, Aug 12, 2010 at 12:02 PM, Владимир wrote:
> Ok, I used opengl extension viewer from realtechvr to identify some
> parameters values, (used some data from win/osx ati drivers) also identified
> most of limits by its normal name.
> the patch conatins some new val
https://bugs.freedesktop.org/show_bug.cgi?id=29540
Brian Paul changed:
What|Removed |Added
Blocks||29044
--
Configure bugmail: https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Brian Paul changed:
What|Removed |Added
Depends on||29540
--
Configure bugmail: https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=29540
Summary: [glsl2] problem with vertex attribute locations and
draw-time validation
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
S
From: Ian Romanick
---
src/glsl/builtin_function.cpp|5 +
src/glsl/builtin_types.h |4
src/glsl/builtins/tools/generate_builtins.pl |5 +
src/glsl/glsl_types.cpp |1 +
src/glsl/ir_variable.cpp
When the compiler was being developed out of tree, I had open-coded
the Elements macro in a couple places. It seems that I never went
back and cleaned that up. This patch should fix that and the issue
that Jakob reported.
Does this fix the original problem?
_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
José Fonseca wrote:
> OK.
>
> What about this:
>
> For GLUT, GLEW, LLVM and all other dependencies I'll just make a SDK
> with the binaries, with debug & release, 32 & 64 bit, MinGW & MSVC
> versions. One seldom needs to modify the source anyway, an
https://bugs.freedesktop.org/show_bug.cgi?id=29537
Ian Romanick changed:
What|Removed |Added
Platform|Other |All
AssignedTo|mesa-...@lists.fre
https://bugs.freedesktop.org/show_bug.cgi?id=29537
Brian Paul changed:
What|Removed |Added
Blocks||29044
--
Configure bugmail: https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Brian Paul changed:
What|Removed |Added
Depends on||29537
--
Configure bugmail: https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=29537
Summary: [glsl2] texture2DLod() should not be accepted by
fragment programs
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severit
https://bugs.freedesktop.org/show_bug.cgi?id=29489
Carl Worth changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
> Hey Luca -- I have to ask how far you're thinking of going with rtasm on
> x86-64... I can say from experience that while it's a nice utility for
> generating very simple assembly (as in translate), as soon as you start
> getting into anything more complex, llvm is by far the better choice...
T
Needed for Elements. Need to have its own extern block before other includes
due to conflicts with other headers which define similar thingsi. In
particular mapi/mapi/u_compiler.h will get included before main/compiler.h and
main/compiler.h doesn't check if INLINE is already defined so we get warni
On Thu, 2010-08-12 at 10:09 -0700, Luca Barbieri wrote:
> This commit adds minimal x86-64 support: only movs between registers
> are supported for r8-r15, and x64_rexw() must be used to ask for 64-bit
> operations.
Hey Luca -- I have to ask how far you're thinking of going with rtasm on
x86-64...
translate_sse is currently very limited to the point of
being useless in essentially all cases.
In particular, it only support some float32 and unorm8
formats and doesn't work on x86-64.
This commit rewrites it to support:
1. Dumb memory copy for any pair of identical formats
2. All formats that
This commit adds minimal x86-64 support: only movs between registers
are supported for r8-r15, and x64_rexw() must be used to ask for 64-bit
operations.
It also adds several new instructions for the new translate_sse code.
---
src/gallium/auxiliary/rtasm/rtasm_cpu.c|6 +-
src/gallium/auxi
Currently, only 32-bit indices are supported, but some use cases
translate needs support for all types.
---
src/gallium/auxiliary/rtasm/rtasm_x86sse.c | 14
src/gallium/auxiliary/rtasm/rtasm_x86sse.h |2 +
src/gallium/auxiliary/translate/translate.h| 12
.
Currently translate_sse puts two trivial wrappers in the translate vtable.
These slow it down and enlarge the source code for no gain, except perhaps
the ability to set a breakpoint there, so remove them.
Breakpoints can be set on the caller of the translate functions, with no
loss of functionali
This moves the common code into a separate ALWAYS_INLINE function.
---
.../auxiliary/translate/translate_generic.c| 175 +++-
1 files changed, 60 insertions(+), 115 deletions(-)
diff --git a/src/gallium/auxiliary/translate/translate_generic.c
b/src/gallium/auxiliary/tran
When used in GPU drivers, translate can be used to simultaneously
perform a gather operation, and convert away from unsupported formats.
In this use case, input and output formats will often be identical: clearly
it would make sense to use a memcpy in this case.
Instead, translate will insist to
This patchset improves translate in several way, with a particular focus
on making it more useful and faster for hardware drivers.
The first part of the patchset is a couple of simple changes: support for
directly using memcpy() if the input and output formats are identical, and
support for 8-bit
On Thu, 2010-08-12 at 08:33 -0700, Matt Turner wrote:
> On Thu, Aug 12, 2010 at 11:27 AM, José Fonseca wrote:
> > On Thu, 2010-08-12 at 07:58 -0700, Matt Turner wrote:
> >> On Thu, Aug 12, 2010 at 7:00 AM, José Fonseca wrote:
> >> >> Really optimising for the wrong bunch of people here by draggin
On 08/12/2010 04:06 AM, Marek Olšák wrote:
> On Wed, Aug 11, 2010 at 10:07 PM, Luca Barbieri wrote:
>
>>> Because all nvidia hardware seems to have the normalized bit as a
>> property
>>> of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all
>> ATI
>>> hardware has the normalized
On 08/12/2010 10:53 AM, tom fogal wrote:
> Can we go the other way? Put OSMesa symbols in libGL?
I gave this a successful try in the other thread. (Sorry for the
braiding of threads)
signature.asc
Description: OpenPGP digital signature
___
mesa-dev m
On Thu, Aug 12, 2010 at 11:27 AM, José Fonseca wrote:
> On Thu, 2010-08-12 at 07:58 -0700, Matt Turner wrote:
>> On Thu, Aug 12, 2010 at 7:00 AM, José Fonseca wrote:
>> >> Really optimising for the wrong bunch of people here by dragging this
>> >> stuff into mesa git.
>> >
>> > Many projects do t
On Thu, 2010-08-12 at 07:58 -0700, Matt Turner wrote:
> On Thu, Aug 12, 2010 at 7:00 AM, José Fonseca wrote:
> >> Really optimising for the wrong bunch of people here by dragging this
> >> stuff into mesa git.
> >
> > Many projects do this: they include the source of other projects, to
> > make it
On 08/06/2010 05:20 PM, tom fogal wrote:
>
> Well, it does appear to be some type of symbol resolution/overloading
> issue. However it seems to be with internal Mesa symbols. Switching
> to a single library -- that is, putting OSMesaCreateContext, etc. into
> libGL directly, and getting rid of l
On Thu, Aug 12, 2010 at 7:00 AM, José Fonseca wrote:
>> Really optimising for the wrong bunch of people here by dragging this
>> stuff into mesa git.
>
> Many projects do this: they include the source of other projects, to
> make it easier to build without having to build all dependencies.
This i
Dan Nicholson writes:
[snip]
> A possible compromise here would be to put glX* stubs in OSMesa, but
> _that_ seems perverse, too.
That would be wonderful for us, though ;)
Can we go the other way? Put OSMesa symbols in libGL?
That feels an iota less gross to me. Still, some day I'd like to pa
"Kevin H. Hobbs" writes:
> On 08/11/2010 05:18 PM, tom fogal wrote:
> > Right. This is exactly why Mesa's name mangling exists.
> > You mean you haven't been mangling this whole time? I guess I haven't
> > been reading these mails closely enough.
>
> It just seems perverse to have to use name ma
On 08/12/2010 07:52 AM, Dan Nicholson wrote:
On Thu, Aug 12, 2010 at 2:07 AM, Kevin H. Hobbs wrote:
On 08/11/2010 05:18 PM, tom fogal wrote:
Right. This is exactly why Mesa's name mangling exists.
You mean you haven't been mangling this whole time? I guess I haven't
been reading these mails c
On Thu, Aug 12, 2010 at 2:07 AM, Kevin H. Hobbs wrote:
> On 08/11/2010 05:18 PM, tom fogal wrote:
>> Right. This is exactly why Mesa's name mangling exists.
>> You mean you haven't been mangling this whole time? I guess I haven't
>> been reading these mails closely enough.
>>
>> -tom
>>
>
> It ju
On 08/12/2010 07:37 AM, Keith Whitwell wrote:
On Thu, 2010-08-12 at 06:28 -0700, Brian Paul wrote:
On 08/12/2010 07:16 AM, Keith Whitwell wrote:
On Thu, 2010-08-12 at 06:08 -0700, Brian Paul wrote:
On 08/11/2010 09:40 PM, Luca Barbieri wrote:
[Apparently bri...@kemper.freedesktop.org is forwa
On Thu, 2010-08-12 at 06:28 -0700, Brian Paul wrote:
> On 08/12/2010 07:16 AM, Keith Whitwell wrote:
> > On Thu, 2010-08-12 at 06:08 -0700, Brian Paul wrote:
> >> On 08/11/2010 09:40 PM, Luca Barbieri wrote:
> >>> [Apparently bri...@kemper.freedesktop.org is forwarded to
> >>> brian.p...@tungstengr
On 08/12/2010 07:16 AM, Keith Whitwell wrote:
On Thu, 2010-08-12 at 06:08 -0700, Brian Paul wrote:
On 08/11/2010 09:40 PM, Luca Barbieri wrote:
[Apparently bri...@kemper.freedesktop.org is forwarded to
brian.p...@tungstengraphics.com, which is no longer valid.]
I'd suggest to put it in stru
On Thu, 2010-08-12 at 06:08 -0700, Brian Paul wrote:
> On 08/11/2010 09:40 PM, Luca Barbieri wrote:
> > [Apparently bri...@kemper.freedesktop.org is forwarded to
> > brian.p...@tungstengraphics.com, which is no longer valid.]
> >
> > I'd suggest to put it in struct pipe_index_buffer.
> >
> > Th
On 08/11/2010 09:40 PM, Luca Barbieri wrote:
[Apparently bri...@kemper.freedesktop.org is forwarded to
brian.p...@tungstengraphics.com, which is no longer valid.]
I'd suggest to put it in struct pipe_index_buffer.
The argument is that the index buffer needs to be prepared
specifically for
On Thu, 2010-08-12 at 04:10 -0700, Dave Airlie wrote:
> On Thu, Aug 12, 2010 at 9:00 PM, José Fonseca wrote:
> > On Wed, 2010-08-11 at 17:40 -0700, Dave Airlie wrote:
> >> On Thu, Aug 12, 2010 at 9:42 AM, José Fonseca wrote:
> >> > On Wed, 2010-08-11 at 12:52 -0700, Ian Romanick wrote:
> >> >> --
On Thu, Aug 12, 2010 at 9:00 PM, José Fonseca wrote:
> On Wed, 2010-08-11 at 17:40 -0700, Dave Airlie wrote:
>> On Thu, Aug 12, 2010 at 9:42 AM, José Fonseca wrote:
>> > On Wed, 2010-08-11 at 12:52 -0700, Ian Romanick wrote:
>> >> -BEGIN PGP SIGNED MESSAGE-
>> >> Hash: SHA1
>> >>
>> >> Jo
On Wed, 2010-08-11 at 17:40 -0700, Dave Airlie wrote:
> On Thu, Aug 12, 2010 at 9:42 AM, José Fonseca wrote:
> > On Wed, 2010-08-11 at 12:52 -0700, Ian Romanick wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> José Fonseca wrote:
> >> > Could then Aras Pranckevicius's tallo
On 08/11/2010 11:55 PM, tom fogal wrote:
> Dan Nicholson writes:
> [snip]
>
>> So, sorry for not reading the whole thread, but is GL being linked
>> because it's needed by the app, because pkg-config said so, or
>> because the linker added it?
>>
> It's needed by the app. Not really, it's
On 08/11/2010 05:18 PM, tom fogal wrote:
> Right. This is exactly why Mesa's name mangling exists.
> You mean you haven't been mangling this whole time? I guess I haven't
> been reading these mails closely enough.
>
> -tom
>
It just seems perverse to have to use name mangling to deal with the
47 matches
Mail list logo
