On 08/11/2010 11:55 PM, tom fogal wrote:
Dan Nicholson dbn.li...@gmail.com 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
On Wed, 2010-08-11 at 17:40 -0700, Dave Airlie wrote:
On Thu, Aug 12, 2010 at 9:42 AM, José Fonseca jfons...@vmware.com 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
On Thu, Aug 12, 2010 at 9:00 PM, José Fonseca jfons...@vmware.com wrote:
On Wed, 2010-08-11 at 17:40 -0700, Dave Airlie wrote:
On Thu, Aug 12, 2010 at 9:42 AM, José Fonseca jfons...@vmware.com wrote:
On Wed, 2010-08-11 at 12:52 -0700, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
On Thu, 2010-08-12 at 04:10 -0700, Dave Airlie wrote:
On Thu, Aug 12, 2010 at 9:00 PM, José Fonseca jfons...@vmware.com wrote:
On Wed, 2010-08-11 at 17:40 -0700, Dave Airlie wrote:
On Thu, Aug 12, 2010 at 9:42 AM, José Fonseca jfons...@vmware.com wrote:
On Wed, 2010-08-11 at 12:52 -0700,
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
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
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...@tungstengraphics.com,
On Thu, Aug 12, 2010 at 2:07 AM, Kevin H. Hobbs hob...@ohiou.edu 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
On 08/12/2010 07:52 AM, Dan Nicholson wrote:
On Thu, Aug 12, 2010 at 2:07 AM, Kevin H. Hobbshob...@ohiou.edu 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
Kevin H. Hobbs hob...@ohiou.edu 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
Dan Nicholson dbn.li...@gmail.com 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
On Thu, Aug 12, 2010 at 7:00 AM, José Fonseca jfons...@vmware.com 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
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
On Thu, 2010-08-12 at 07:58 -0700, Matt Turner wrote:
On Thu, Aug 12, 2010 at 7:00 AM, José Fonseca jfons...@vmware.com 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
On Thu, Aug 12, 2010 at 11:27 AM, José Fonseca jfons...@vmware.com wrote:
On Thu, 2010-08-12 at 07:58 -0700, Matt Turner wrote:
On Thu, Aug 12, 2010 at 7:00 AM, José Fonseca jfons...@vmware.com wrote:
Really optimising for the wrong bunch of people here by dragging this
stuff into mesa git.
On 08/12/2010 04:06 AM, Marek Olšák wrote:
On Wed, Aug 11, 2010 at 10:07 PM, Luca Barbieri l...@luca-barbieri.comwrote:
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
On Thu, 2010-08-12 at 08:33 -0700, Matt Turner wrote:
On Thu, Aug 12, 2010 at 11:27 AM, José Fonseca jfons...@vmware.com wrote:
On Thu, 2010-08-12 at 07:58 -0700, Matt Turner wrote:
On Thu, Aug 12, 2010 at 7:00 AM, José Fonseca jfons...@vmware.com wrote:
Really optimising for the wrong
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
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
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
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 +-
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
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... I
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
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...
The
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
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Brian Paul brian.e.p...@gmail.com changed:
What|Removed |Added
Depends on||29537
--
Configure
https://bugs.freedesktop.org/show_bug.cgi?id=29537
Brian Paul brian.e.p...@gmail.com changed:
What|Removed |Added
Blocks||29044
--
Configure
https://bugs.freedesktop.org/show_bug.cgi?id=29537
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
Platform|Other |All
From: Ian Romanick ian.d.roman...@intel.com
---
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 +
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
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Brian Paul brian.e.p...@gmail.com changed:
What|Removed |Added
Depends on||29540
--
Configure
https://bugs.freedesktop.org/show_bug.cgi?id=29540
Brian Paul brian.e.p...@gmail.com changed:
What|Removed |Added
Blocks||29044
--
Configure
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Gordon Jin gordon@intel.com changed:
What|Removed |Added
Depends on||29496
--
Configure
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Gordon Jin gordon@intel.com changed:
What|Removed |Added
Depends on||29498
--
Configure
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Gordon Jin gordon@intel.com changed:
What|Removed |Added
Depends on||29524
--
Configure
36 matches
Mail list logo
