Re: [Mesa3d-dev] [PATCH] Document TGSI LOOP/ENDLOOP instructions.
Brian Paul pisze: Michał Król wrote: Brian Paul pisze: I think I'd prefer to rename the simple LOOP2/ENDLOOP2 instructions as LOOP/ENDLOOP and call the above functions LOOP_COUNT/ENDLOOP_COUNT. I am all for renaming, but just to make them shorter, what about the following renaming? LOOP = FORLOOP ENDLOOP = ENDFOR BGNLOOP2 = BGNLOOP ENDLOOP2 = ENDLOOP How about LOOP = BGNFOR to be symmetric with ENDFOR? Yes, certainly. I am pushing a change for the master branch. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Document TGSI LOOP/ENDLOOP instructions.
Brian Paul pisze: Michał Król wrote: The LOOP/ENDLOOP opcodes have been loosely defined in gallium and the de-facto definition had redundant semantics to BGNLOOP2/ENDLOOP2. This patch documents this pair to closely match GL_NV_fragment_program2 LOOP/ENDLOOP behaviour. Fixes into the code will follow after this has been accepted. diff --git a/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt b/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt index a3f4947..7b3e419 100644 --- a/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt +++ b/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt @@ -667,7 +667,15 @@ TGSI Instruction Specification 1.9.8 LOOP - Loop - TBD + dst.x = floor(src.x) + dst.y = floor(src.y) + dst.z = floor(src.z) + + if (dst.y = 0) +pc = [matching ENDLOOP] + 1 + endif + + Note: The destination must be a loop register. 1.9.9 REP - Repeat @@ -687,7 +695,14 @@ TGSI Instruction Specification 1.9.12 ENDLOOP - End Loop - TBD + dst.x = dst.x + dst.z + dst.y = dst.y - 1.0 + + if (dst.y 0) +pc = [matching LOOP instruction] Fix: pc = [matching LOOP instruction] + 1 Thanks. + endif + + Note: The destination must be a loop register. I think you have dst.x and dst.y mixed up in a few places there. The NV spec says .x is the loop count. That was a deliberate move to have the index in an .x component. The .y and .z components should be not accessible to the application. In GL_NV_fragment_program2.txt the loop count/index/incr are hidden values which can't be accessed by other instructions inside the loop. The index can be accessed as A0.x. A new LOOP register file should be introduced, with only the .x component (index) being accessible. Also, the loop count must be a constant, etc. Are we imposing those policies here too? If so, that should be documented. Yes, we should do it. I think I'd prefer to rename the simple LOOP2/ENDLOOP2 instructions as LOOP/ENDLOOP and call the above functions LOOP_COUNT/ENDLOOP_COUNT. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Document TGSI LOOP/ENDLOOP instructions.
diff --git a/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt b/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt index a3f4947..5f88cc2 100644 --- a/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt +++ b/src/gallium/auxiliary/tgsi/tgsi-instruction-set.txt @@ -667,7 +667,16 @@ TGSI Instruction Specification 1.9.8 LOOP - Loop - TBD + dst.x = floor(src.x) + dst.y = floor(src.y) + dst.z = floor(src.z) + + if (dst.y = 0) +pc = [matching ENDLOOP] + 1 + endif + + Note: The destination must be a loop register. +The source must be a constant register. 1.9.9 REP - Repeat @@ -687,7 +696,14 @@ TGSI Instruction Specification 1.9.12 ENDLOOP - End Loop - TBD + dst.x = dst.x + dst.z + dst.y = dst.y - 1.0 + + if (dst.y 0) +pc = [matching LOOP instruction] + 1 + endif + + Note: The destination must be a loop register. 1.9.13 ENDREP - End Repeat -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] pipe_format lookup table
José Fonseca pisze:
On Tue, 2009-07-28 at 08:09 -0700, Michał Król wrote:
José Fonseca pisze:
I found one other problem in the way we use 4 x 8bit color formats:
sometimes we interpret them as arithmetically coded in an unsigned (e.g
src/gallium/auxiliary/util/u_tile.c when reading/writing
color/depth/stencil buffers), sometimes we interpret them (e.g.
src/gallium/auxiliary/translate/translate_generic.c when reading/writing
vertex buffers). And these actually mean different things on
little-endian architectures.
Some text is missing from the first sentence. I am guessing that
sometimes we interpret them as an array of bytes, right?
Right ;)
I think the only viable option is to distinguish between these two kinds
in the cases where it is ambiguous, like
PIPE_FORMAT_R8G8B8A8_UNORM /* a | ( b 8) | (g 8) | (r 24) */
PIPE_FORMAT_RGBA8_UNORM /* {r, g, b, a} */
Since there are legitimate uses in for both (color buffers, and vertex
buffers).
Anybody has better ideas?
We should go with and stick to a single convention. I don't know, maybe
for example this:
A16R16G16B16
The format description above would indicate that we are dealing with a
64-bit entity with bits being numbered from right to left. That would
mean the B component occupies first 16 bits (bytes 0:1), the G component
next 16 bits (bytes 2:3) and so on. Because there is no implied dword
and encoding using shifts, we could easily write some code that decodes
the format in a portable way across LE and BE architectures.
Are these semantics followed by GL? (D3D does't matter much since it is
only used on x86 anyway). Because if not we need to choose different
formats according to the endianness.
I don't think they follow them everywhere. But the point is we can just
look at GL spec, see the convention and try to match it to a gallium format.
Note also that formats like A1R5G5B5 can only be defined in terms of
shits. Furthermore, the channel that starts from bit 0 is B, and not A
as one would conclude from the your rule above.
Well, yes and no. Let's break A1R5G5B5 into bits using my definition.
15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
A R R R R R G G G G G B B B B B
It means B is in byte 0, G in bytes 0 and 1, R and A are in byte 1. To
extract them correctly you need to use masking and shifting wisely, but
because you do it on a byte level, you are not concerned about
endianness, as endianness is about byte ordering in a word, not bit
ordering in a byte. The concept of a word does not exist here.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] gallium: remove deprecated TGSI opcodes
Keith Whitwell pisze: Various opcodes which can be implemented trivially with other TGSI opcodes, such as matrix multiplication and negation. These were not used by any state tracker or implemented by any of the drivers. Looks good. Thanks. -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] gallium: clean up opcode definitions
Keith Whitwell pisze: Remove commented-out opcodes. Remove information about API mappings to opcodes, but add a reference to tgsi-instruction-set.txt where that information is better presented. Looks nice, thanks for that. It looks like I will have to focus and finish up this tgsi-instruction-set.txt documentation. -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] gallium: simplify tgsi_full_immediate struct
Keith Whitwell pisze: Remove the need to have a pointer in this struct by just including the immediate data inline. Having a pointer in the struct introduces complications like needing to alloc/free the data pointed to, uncertainty about who owns the data, etc. There doesn't seem to be a need for it, and it is unlikely to make much difference plus or minus to performance. Added some asserts as we now will trip up on immediates with more than four elements. There were actually already quite a few such asserts, but the 4 case could be used in the future to specify indexable immediate ranges, such as lookup tables. This also looks OK. Thanks again. -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] gallium: simplify tgsi_full_immediate struct
Keith Whitwell pisze: Remove the need to have a pointer in this struct by just including the immediate data inline. Having a pointer in the struct introduces complications like needing to alloc/free the data pointed to, uncertainty about who owns the data, etc. There doesn't seem to be a need for it, and it is unlikely to make much difference plus or minus to performance. This patch is OK, though it heavily relies on the fact the immediates are always stored as float quadruplets. We either need to add a bunch of asserts about that, or specialise the tgsi representation by removing NrTokens field and make it explicit we are dealing with exactly four values, not (NrTokens-1). -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] gallium: simplify tgsi_full_immediate struct
Keith Whitwell pisze: On Wed, 2009-07-22 at 01:35 -0700, Michał Król wrote: Keith Whitwell pisze: Remove the need to have a pointer in this struct by just including the immediate data inline. Having a pointer in the struct introduces complications like needing to alloc/free the data pointed to, uncertainty about who owns the data, etc. There doesn't seem to be a need for it, and it is unlikely to make much difference plus or minus to performance. This patch is OK, though it heavily relies on the fact the immediates are always stored as float quadruplets. We either need to add a bunch of asserts about that, or specialise the tgsi representation by removing NrTokens field and make it explicit we are dealing with exactly four values, not (NrTokens-1). I don't think it relies on this at all. Can you be more specific what you think has been lost? Immediates with less than four values will be handled fine, with some of the slots in the full_immediate struct remaining unused. This is the same as all the other tgsi_full_* structs -- they all have slots that don't always get populated. The NrTokens field retains its meaning, and the tokenized representation of programs isn't changed by this patch. Also, if we ever support non-float immediates, that can be handled by this change just as well as previously -- ie. by adding an Unsigned value to the union tgsi_immediate_data. Yes, that is all correct. Though, nothing stops us from having more than 4 values in an immediate declartion. You have a valid point that there can be less than 4 values, hence NrTokens must stay, but we still need to assert on (NrTokens = 4+1). -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] gallium: remove multiple aliases for TGSI opcodes
Keith Whitwell pisze: /* * GL_EXT_vertex_shader */ #define TGSI_OPCODE_INDEX 22 /* considered for removal */ #define TGSI_OPCODE_NEGATE 23 /* considered for removal */ -#define TGSI_OPCODE_MADDTGSI_OPCODE_MAD -#define TGSI_OPCODE_FRAC24 -#define TGSI_OPCODE_SETGE TGSI_OPCODE_SGE -#define TGSI_OPCODE_SETLT TGSI_OPCODE_SLT +/*#define TGSI_OPCODE_INDEX 22 */ +/*#define TGSI_OPCODE_NEGATE 23 */ That doesn't look right. The last 2 lines should go. Thanks for the patch. -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): scons: Don't use deprecated Options.
José Fonseca pisze: On Thu, 2009-05-07 at 14:57 -0700, Michał Król wrote: José Fonseca pisze: Michal, You scons version is very old. Too old I'm afraid, as recent scons versions starting to complain about using the deprecated *Options* symbols. Can you upgrade to scons 1.1 or 1.2? Thanks. It looks like a simple apt-get upgrade is not sufficent and won't get me scons better than 0.97. Which ubuntu version are you using? Perhaps you need to edit /etc/apt/sources.list and ensure you have the xxx-updates enabled. If that still doesn't work, then it might be better to switch to a new ubuntu release, also by editing /etc/apt/sources.list and then running apt-get dist-upgrade. Yes, I was thinking about taking this route and upgrading from 8.04 to 9.04. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): scons: Don't use deprecated Options.
CCing mesa3d-dev.
Michał Król pisze:
Keith Whitwell pisze:
Module: Mesa
Branch: master
Commit: e9fb90ab8889136f788a3d9dc395b0f4d46cfdcc
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=e9fb90ab8889136f788a3d9dc395b0f4d46cfdcc
Author: José Fonseca jfons...@vmware.com
Date: Fri May 1 16:12:17 2009 +0100
scons: Don't use deprecated Options.
This is breaking my nightly builds on ubuntu x64.
scons --version
SCons by Steven Knight et al.:
engine: v0.97.0d20071203.r2509, 2007/12/03 20:20:38, by broonie on
mercator
Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007 The SCons Foundation
scons statetrackers=python debug=1
scons: Reading SConscript files ...
NameError: name 'Variables' is not defined:
File /home/michal/src/mesa/SConstruct, line 44:
opts = Variables('config.py')
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): scons: Don't use deprecated Options.
José Fonseca pisze: Michal, You scons version is very old. Too old I'm afraid, as recent scons versions starting to complain about using the deprecated *Options* symbols. Can you upgrade to scons 1.1 or 1.2? Thanks. It looks like a simple apt-get upgrade is not sufficent and won't get me scons better than 0.97. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): pipe: Get the p_atomic_dec_zero logic right this time.
José Fonseca pisze:
On Tue, 2009-04-21 at 02:52 -0700, Michał Król wrote:
Jose Fonseca pisze:
Module: Mesa
Branch: master
Commit: 86ed894e47bae10d158f2b4a02065daa9dbe5194
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=86ed894e47bae10d158f2b4a02065daa9dbe5194
Author: José Fonseca jfons...@vmware.com
Date: Fri Apr 17 18:40:46 2009 +0100
pipe: Get the p_atomic_dec_zero logic right this time.
---
src/gallium/include/pipe/p_atomic.h |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/gallium/include/pipe/p_atomic.h
b/src/gallium/include/pipe/p_atomic.h
index ed5f665..0c3fbae 100644
--- a/src/gallium/include/pipe/p_atomic.h
+++ b/src/gallium/include/pipe/p_atomic.h
@@ -225,7 +225,7 @@ p_atomic_cmpxchg(struct pipe_atomic *v, int32_t old,
int32_t _new)
struct pipe_atomic
{
- long count;
+ volatile long count;
};
Jose,
Could you explain why the `volatile' keyword above is necessary? We are
using InterlockedDecrement/Increment() functions to operate on it, and I
believe any function call should be a sufficient memory barrier.
Michal,
I added the volatile keyword because many of the InterlockedIncrement
examples I found in internet use the volatile keyword, and the
InterlockedIncrement/Decrement function themselves have volatile pointer
as their arguments.
See http://msdn.microsoft.com/en-us/library/f24ya7ct(VS.71).aspx for an
example. But you can also find examples that don't.
In my interpretation volatile makes sense -- the variable can change at
any time, and we don't want the compiler to keep a local/outdated copy
in a register.
This is a common misconception. When I was young I thought the same, but
now I am a convertee.
The `volatile' qualifier doesn't mean that the variable is going to be
put in some special memory location that forces the CPU to behave in a
desired way (this is different than, say, `align' qualifier that makes
the compiler put the variable at e.g. word boundaries). It's all about
how the compiler is going to handle variables declared that way.
InterlockedXXX() functions can be translated into intrinsics which means
there could be no memory barrier after optimistation. Note however that
the `volatile' keyword in formal argument declaration guarantees the
actual argument is going to be treated as such event if it was not
declared volatile in the first place.
http://www.tech-archive.net/Archive/VC/microsoft.public.vc.mfc/2005-01/0702.html
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): pipe: Get the p_atomic_dec_zero logic right this time.
José Fonseca pisze:
On Wed, 2009-04-22 at 01:09 -0700, Michał Król wrote:
José Fonseca pisze:
On Tue, 2009-04-21 at 02:52 -0700, Michał Król wrote:
Jose Fonseca pisze:
Module: Mesa
Branch: master
Commit: 86ed894e47bae10d158f2b4a02065daa9dbe5194
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=86ed894e47bae10d158f2b4a02065daa9dbe5194
Author: José Fonseca jfons...@vmware.com
Date: Fri Apr 17 18:40:46 2009 +0100
pipe: Get the p_atomic_dec_zero logic right this time.
---
src/gallium/include/pipe/p_atomic.h |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/gallium/include/pipe/p_atomic.h
b/src/gallium/include/pipe/p_atomic.h
index ed5f665..0c3fbae 100644
--- a/src/gallium/include/pipe/p_atomic.h
+++ b/src/gallium/include/pipe/p_atomic.h
@@ -225,7 +225,7 @@ p_atomic_cmpxchg(struct pipe_atomic *v, int32_t old,
int32_t _new)
struct pipe_atomic
{
- long count;
+ volatile long count;
};
Jose,
Could you explain why the `volatile' keyword above is necessary? We are
using InterlockedDecrement/Increment() functions to operate on it, and I
believe any function call should be a sufficient memory barrier.
Michal,
I added the volatile keyword because many of the InterlockedIncrement
examples I found in internet use the volatile keyword, and the
InterlockedIncrement/Decrement function themselves have volatile pointer
as their arguments.
See http://msdn.microsoft.com/en-us/library/f24ya7ct(VS.71).aspx for an
example. But you can also find examples that don't.
In my interpretation volatile makes sense -- the variable can change at
any time, and we don't want the compiler to keep a local/outdated copy
in a register.
This is a common misconception. When I was young I thought the same, but
now I am a convertee.
The `volatile' qualifier doesn't mean that the variable is going to be
put in some special memory location that forces the CPU to behave in a
desired way (this is different than, say, `align' qualifier that makes
the compiler put the variable at e.g. word boundaries). It's all about
how the compiler is going to handle variables declared that way.
I know volatile doesn't force the CPU to behave in any special way.
That's why I said compiler above, and not CPU.
InterlockedXXX() functions can be translated into intrinsics which means
there could be no memory barrier after optimistation. Note however that
the `volatile' keyword in formal argument declaration guarantees the
actual argument is going to be treated as such event if it was not
declared volatile in the first place.
http://www.tech-archive.net/Archive/VC/microsoft.public.vc.mfc/2005-01/0702.html
Without volatile keyword, nothing prevents the compiler of translating
while(p_atomic_read(v)) {
// some work
}
into
eax = v-count;
if(eax) {
for( ;; ) { // infinite loop !!
// some work
}
}
ie. factoring successive reads of p_atomic_read into a single read,
since p_atomic_read is not an intrinsic, but defined as
#define p_atomic_read(_v) ((_v)-count)
Jose
OK, that makes sense, sorry about the fuss. I was thinking about it in
the context of _InterlockedXXX() usage only.
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] softpipe: X8R8G8B8 rendertarget artifacts
Attached a screenshot from python state tracker's vertex-shader regress test using X8R8G8B8 rendertarget. Color clear value has been set to 0x80808080. Run on linux-x86-64-debug, ubuntu, softpipe, X11. Changing rendertarget format to A8R8G8B8 cures the problem. -- Pozdrawiam, Michal Krol attachment: vert-mov.png-- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] softpipe: X8R8G8B8 rendertarget artifacts
2009/4/3 Brian Paul bri...@vmware.com: Michał Król wrote: Attached a screenshot from python state tracker's vertex-shader regress test using X8R8G8B8 rendertarget. Color clear value has been set to 0x80808080. Run on linux-x86-64-debug, ubuntu, softpipe, X11. Changing rendertarget format to A8R8G8B8 cures the problem. Does the attached patch help? Looks like we need to add some missing switch cases... Yes, that works. Thanks. -- Pozdrawiam, Michal Krol -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): gallium: Implement atomic interface for windows user mode subsystem.
Ian Romanick pisze: Synchronization, memory barriers, atomic operations, etc. are all dark voodoo. It's one of those things like crypto that really should be left to the experts. Re-inventing it is almost universally the wrong choice. Ian, How would we use libatomic_ops in Windows environment? Would libatomic code be an integral part of gallium codebase or would it be something the end user would have to pull in from external source in order to compile mesa? -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): gallium: Implement atomic interface for windows user mode subsystem.
Ian Romanick pisze: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michał Król wrote: Ian Romanick pisze: Synchronization, memory barriers, atomic operations, etc. are all dark voodoo. It's one of those things like crypto that really should be left to the experts. Re-inventing it is almost universally the wrong choice. Ian, How would we use libatomic_ops in Windows environment? Would libatomic code be an integral part of gallium codebase or would it be something the end user would have to pull in from external source in order to compile mesa? I'd expect the user would have to pull it from upstream. I think there is a Windows build available, so that should be too difficult. If there isn't we could make a Windows build available on mesa3d.org. This wouldn't be any different that with LLVM, right? But is it really worth the effort for such a primitve functionality as atomic ops? Especially when the operating system provides you with a neat set of entry points that let you do things with a single call? I hardly agree that atomic operations are magic and require non-trivial amount of effort to do right. I haven't looked at libatomic's sources, but I bet its value is in a fine support for multitude of systems out there. I am affraid we are not the target audience of the library in question -- if you do some big fancy multithreaded math app it makes sense to pull in the library and recompile the code for a new platform. For gallium, however, porting to a new environment is a challenge and an ultimate goal of gallium development. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] gallium: Add simple atomic class api.
On Mon, Mar 16, 2009 at 10:41 AM, Thomas Hellstrom
thellst...@vmware.com wrote:
tom fogal wrote:
thellst...@vmware.com writes:
[snip]
+#if (defined(PIPE_CC_GCC) defined(__i386__))
^
This is basically an #ifdef (__GNUC__), I'm guessing?
Yes, however it seems like the rest of the gallium code is using private
defines for this, so
I'll stick to that.
+struct pipe_atomic {
+ int32_t count;
+};
[snip]
+static INLINE int32_t
+p_atomic_cmpxchg(struct pipe_atomic *v, int32_t old, int32_t new)
+{
+ int32_t previous;
+
+ __asm__ __volatile__(lock; cmpxchgl %k1,%2:=a(previous)
+ :r(new), m(v-count), 0(old)
+ :memory);
+
+ return previous;
+}
If the code is only compiled on gcc anyway, it seems like one could
apply the atomics primitives provided by the compiler:
http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Atomic-Builtins.html
That might allow you to remove the __i386__ qualification as well.
(Note that I've never tried these extensions, just an idea.)
-tom
Thanks for the hint!
The code is not only for GCC, but we'll probably have to code up a lot
of special cases, so this will definitely help.
I'll give it a check.
Shouldn't we be using PIPE_ARCH_X86 instead of __i386__?? See `pipe/p_config.h'.
#if defined(__i386__) /* gcc */ || defined(_M_IX86) /* msvc */ ||
defined(_X86_) || defined(__386__) || defined(i386)
#define PIPE_ARCH_X86
#endif
--
Pozdrawiam,
Michal Krol
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): gallium: Implement atomic for MSVC on x86.
On Mon, Mar 16, 2009 at 1:59 PM, José Fonseca jfons...@vmware.com wrote:
Shouldn't we use InterlockedIncrement
( http://msdn.microsoft.com/en-us/library/ms683614(VS.85).aspx ) and
friends in Windows instead of assembly? It is implemented as a compiler
intrinsic, so it probably results in more efficient generated code.
I am using InterlockedIncrement for windows user subsystem -- see my
previous commit. (MSCV X86) seems to have a broader scope than
WINDOWS_SUBSYSTEM_USER alone.
What about kernel subsystem? Are there also atomic functions that are
intrinsic? Anyway, feel free to shuffle #ifdefs around.
On Mon, 2009-03-16 at 05:42 -0700, Micha?? Kr??l wrote:
Module: Mesa
Branch: master
Commit: c97b671d64a5f137177989a28c684a13b5cb249b
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=c97b671d64a5f137177989a28c684a13b5cb249b
Author: Michal Krol mic...@vmware.com
Date: Mon Mar 16 13:42:22 2009 +0100
gallium: Implement atomic for MSVC on x86.
---
src/gallium/include/pipe/p_atomic.h | 66
++-
1 files changed, 65 insertions(+), 1 deletions(-)
diff --git a/src/gallium/include/pipe/p_atomic.h
b/src/gallium/include/pipe/p_atomic.h
index 13866d2..b9bf711 100644
--- a/src/gallium/include/pipe/p_atomic.h
+++ b/src/gallium/include/pipe/p_atomic.h
@@ -66,7 +66,71 @@ p_atomic_cmpxchg(struct pipe_atomic *v, int32_t old,
int32_t new)
return __sync_val_compare_and_swap(v-count, old, new);
}
-#elif (defined(PIPE_SUBSYSTEM_WINDOWS_USER)) /* (defined(PIPE_CC_GCC)) */
+#elif (defined(PIPE_ARCH_X86) defined(PIPE_CC_MSVC)) /*
(defined(PIPE_CC_GCC)) */
+
+struct pipe_atomic
+{
+ int32_t count;
+};
+
+#define p_atomic_set(_v, _i) ((_v)-count = (_i))
+#define p_atomic_read(_v) ((_v)-count)
+
+static INLINE boolean
+p_atomic_dec_zero(struct pipe_atomic *v)
+{
+ int32_t *pcount = v-count;
+ unsigned char c;
+
+ __asm {
+ mov eax, [pcount]
+ lock dec dword ptr [eax]
+ sete byte ptr [c]
+ }
+
+ return c != 0;
+}
+
+static INLINE void
+p_atomic_inc(struct pipe_atomic *v)
+{
+ int32_t *pcount = v-count;
+
+ __asm {
+ mov eax, [pcount]
+ lock inc dword ptr [eax]
+ }
+}
+
+static INLINE void
+p_atomic_dec(struct pipe_atomic *v)
+{
+ int32_t *pcount = v-count;
+
+ __asm {
+ mov eax, [pcount]
+ lock dec dword ptr [eax]
+ }
+}
+
+static INLINE int32_t
+p_atomic_cmpxchg(struct pipe_atomic *v, int32_t old, int32_t new)
+{
+ int32_t *pcount = v-count;
+ int32_t orig;
+
+ __asm {
+ mov ecx, [pcount]
+ mov eax, [old]
+ mov edx, [new]
+ lock cmpxchg [ecx], edx
+ mov [orig], eax
+ }
+
+ return orig;
+}
+
+#elif (defined(PIPE_SUBSYSTEM_WINDOWS_USER)) /* (defined(PIPE_ARCH_X86)
defined(PIPE_CC_MSVC)) */
struct pipe_atomic
{
___
mesa-commit mailing list
mesa-com...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-commit
--
Pozdrawiam,
Michal Krol
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): gallium: Implement atomic for MSVC on x86.
José Fonseca pisze: On Mon, 2009-03-16 at 06:09 -0700, Michał Król wrote: On Mon, Mar 16, 2009 at 1:59 PM, José Fonseca jfons...@vmware.com wrote: Shouldn't we use InterlockedIncrement ( http://msdn.microsoft.com/en-us/library/ms683614(VS.85).aspx ) and friends in Windows instead of assembly? It is implemented as a compiler intrinsic, so it probably results in more efficient generated code. I am using InterlockedIncrement for windows user subsystem -- see my previous commit. (MSCV X86) seems to have a broader scope than WINDOWS_SUBSYSTEM_USER alone. Sorry. I missed it. Looks good. What about kernel subsystem? Are there also atomic functions that are intrinsic? Anyway, feel free to shuffle #ifdefs around. The intrinsic are ultimately provided by the compiler. So it should be possible to use them in the kernel too, regardless of the headers. But the only place we care for windows kernel is d3d, and it is single threaded anyway, so pipe_reference should not use atomic instructions there anyway OK, that means we need to explicitly add atomic entry points for display miniport subsystem that practice unprotected reference counting. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Tool to process .syn files?
On 17/05/07, Brian Paul [EMAIL PROTECTED] wrote:
Ian Romanick wrote:
Is there an easy way in this parser generator to change the grammar for
the TXP instruction? Basically, I want it to be invalid to use TXP with
the SHADOWARRAY2D target.
Michael would have to answer that. Michael?
I will look at it tomorrow.
Alternately, is there a reason we're using this instead of lex yacc?
I think Michael just used what was familiar to him.
I used lex yacc to write a unified parser for another project that
handles ARB_{vertex,fragment}_program (up to vp3 and fp2), the various
NV vertex and fragment programs, and ATI_text_fragment_shader. I could
probably adapt it to work with Mesa without too much trouble.
Opinions?
I guess I'd prefer using standard tools like lexx and yacc. Though, I'd
do research to see if there's anything newer/nicer nowadays.
If my memory serves me right, there was at least one attempt in the
past to kill off those syn files, but they are still alive to this
day.
Ian, if this is no problem for you, feel free to replace it with yacc
grammars, just please keep the old ones #ifdefed for a while, if
possible. The reason I used custom grammar in the first place was that
I wasn't aware of any (not only open source) compiler-compiler (lack
of Internet!) so I just invented one.
--
Pozdrawiam,
Michal Krol
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Git clone: Not a valid object name HEAD
On 30/04/07, Mikael Eriksson [EMAIL PROTECTED] wrote: Michał Król skrev: Hello, Using git on cygwin I get the following log. $ git clone git+ssh://[EMAIL PROTECTED]/git/mesa/mesa Initialized empty Git repository in /home/mjkrol/mesa/.git/ Enter passphrase for key '/home/mjkrol/.ssh/id_dsa': Generating pack... Done counting 110735 objects. Packing 110735 objects Indexing 110735 objects. 100% (110735/110735) done Resolving 85660 deltas. 100% (85660/85660) done : not a valid SHA107e6f83f50a28d9bbb51f5ad51be4 fatal: Not a valid object name HEAD Any ideas? IIRC git on cygwin doesn't work on FAT32, try swithing to NTFS. Indeed, I am using NTFS. :( -- Pozdrawiam, Michal Krol - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] current cvs build broken on windows
On 13/10/06, Ian Romanick [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Micha? Król wrote: I cannot successfully link current cvs mesa on Visual C++ 6.0. The error log follows. All of those symbols should come from src/mesa/main/dispatch.c. After having this come up again and again, it's pretty obvious the VC++ has some additional expectations of symbols over every other compiler in the known universe. Could someone please enlighten me as to what that might be? Looks like the missing entries should be defined in wmesa.c as dummy functions. -- Pozdrawiam, Michal Krol - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] glIsProgram missing?
On 06/10/06, David Cole [EMAIL PROTECTED] wrote: First post to mesa lists... hopefully this is the right place for this question: The ability to icorporate custom GLSL shaders was recently added to VTK. However, our tests of this fail when VTK is linked using mesa apparently because there is no glIsProgram symbol. We use an OpenGL extensions manager object to query for it and it's not there. Are we doing something wrong or is there something missing from mesa?? GL_ARB_shader_objects extension does not define glIsProgram function. To check if a given program handle is valid, simply test it against 0. -- Pozdrawiam, Michal Krol - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)
On 21/09/06, Keith Whitwell [EMAIL PROTECTED] wrote: If anyone knows why these emails are turning out all screwed up and missing the newlines, please let me know. I'm just using thunderbird on ubuntu and it's a suprise that such a politically correct distro can't handle emails that involve non-english characters. Maybe it's because of Michel's last name and the a character? I had the same problem with my first name's l character, too. -- Pozdrawiam, Michal Krol - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] GLSL preprocessor
Jeffrey, I am assuming that you are not going to submit your GLSL preprocessor code any time soon so I'm going to do it myself. I need it to finish leftover functionality at the front-end part of the compiler and I would like it to be complete for the Mesa 6.6 release. Thanks. -- Pozdrawiam, Michal Krol - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Can Mesa be compiled with hardware acceleration for windows ?
On 16/09/06, tscmga [EMAIL PROTECTED] wrote: Hi! Can Mesa be compiled with hardware acceleration under windows ? Our game crashes on an Intel on_board graphic card(blue screen ).I want to compiled an ICD opengl driver ,and find out what causes the error. I am not 100% sure, but I would bet it does not. Anyways, why do you need hw acceleration to debug your program? Using sofware GL to do this is perfectly valid. -- Pozdrawiam, Michal Krol - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] 6.5.1 release plan
On 15/09/06, Michał Król [EMAIL PROTECTED] wrote: On 15/09/06, Brian Paul [EMAIL PROTECTED] wrote: Otherwise, can you find a working #ifdef test for Windows? Change this: #elif defined(__UNIXOS2__) || defined(__SOL64__) typedef long int int32_t; typedef long long int int64_t; typedef unsigned long long int uint64_t; #elif defined(WIN32) defined(__GNUC__) #include stdint.h #else #include inttypes.h /* Fallback option */ #endif #endif to this: #elif defined(__UNIXOS2__) || defined(__SOL64__) typedef long int int32_t; typedef long long int int64_t; typedef unsigned long long int uint64_t; #elif defined(WIN32) defined(_MSC_VER) typedef long int int32_t; typedef __int64 int64_t; typedef unsigned __int64 uint64_t; #elif defined(WIN32) defined(__GNUC__) #include stdint.h #else #include inttypes.h /* Fallback option */ #endif #endif I don't own VC7, but further changing this: #elif defined(WIN32) defined(_MSC_VER) to this: #elif defined(WIN32) defined(_MSC_VER) _MSC_VER1300 should work on VC6 and VC7, but the previous code should not break VC7 either. -- Pozdrawiam, Michal Krol - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)
On 01/08/06, Brian Paul [EMAIL PROTECTED] wrote: Michal Krol wrote: CVSROOT: /cvs/mesa Module name: Mesa Repository: Mesa/include/GL/ Changes by: [EMAIL PROTECTED] 06/08/01 17:56:27 Log message: Fix GL_MESA_shader_debug for glut.h. You should be using GLuint instead of unsigned int. GLhandleARB is defined as unsigned int. The way it is now is not good, MESA_shader_debug depends on ARB_shader_objects, which in turn is defined in glext. I will have to make some #ifdefs that exclude the extension for glut builds. -- Pozdrawiam, Michal Krol - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] shaders
On 02/06/06, Philipp Klaus Krause [EMAIL PROTECTED] wrote: I'll have a look at it and maybe send patches. For most drivers fixed-function TcL and vertex programs are done in software, so I don't think that being a software path is an argument against vertex shaders there. Beware, some functionality is still missing: - preprocessor, - type checking, - dFdx, dFdy functions, - AFAIR, when texture sampling, lambda is not taken into account. -- Pozdrawiam, Michal Krol ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Re: DRI and Mesa core patch for GLSL varyings
On 06/04/06, Brian Paul [EMAIL PROTECTED] wrote: I think the arbitrary-length bitset type is overkill. We really just need a 64-bit bitfield for the foreseeable future, right? These macros in bitset.h are pretty heavy if all the bitsets are just 64 bits or less. [...] The code would be far more efficient this way. What do you think? I still need to review the rest of the patch in more detail. Maybe this evening - I've got other things I need to work on. The specialization given above is okay, but to make it future proof, I would suggest the following. 1) Leave the generic bitset macros as they are. 2) Suffix 64-bit versions with 64, e.g. BITSET64_COPY. 3) In t_context.h, where DECLARE_RENDER_INPUTS is declared, also define macro names for operations, not just declarations, e.g. #define RENDERINPUTS_COPY(x,y) BITSET64_COPY(x,y) ... and then use them in drivers and mesa core, in place of BITSET_* as it is now, in the patch. This way we can do transition to, say, 128-bit flags without touching drivers. Also, this reduces the overall burden, when more bit-fields will need multi-word handling. This will happen to swrast, when more than 64 varyings are needed. For now, I just need a confirmation that my changes will not break compilation of drivers. Then I can safely apply your proposals in my next cvs commit. -- Pozdrawiam, Michal Krol --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] TnL changes
On 03/04/06, Keith Whitwell [EMAIL PROTECTED] wrote: The way this has been done before is that you should ensure that the drivers (especially the DRI drivers) at least compile with your changes, and you should do your very best to ensure that your changes do the right thing... Before you commit anything, please post a debugged patch for review. Can you manage that? Does anyone not feel that this is still a reasonable way to do things? OK. I will post a patch tomorrow instead of commiting changes. I am able only to test if the drivers compile. The procedure I've taken, that is, renaming affected variables and removing all _TNL_BIT_* defines, _should_ eliminate problems if compile errors are eliminated. -- Pozdrawiam, Michal Krol --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)
On 27/02/06, Keith Whitwell [EMAIL PROTECTED] wrote: Michal Krol wrote: CVSROOT: /cvs/mesa Module name: Mesa Repository: Mesa/windows/VC6/mesa/osmesa/ Changes by: [EMAIL PROTECTED] 06/02/27 14:41:42 Log message: More GLSL code: - add x86 code generator; Michal, I can't tell you how pleased I am to see the rtasm/ code getting used for this! It looks like you've taken it to the next level in terms of applying it to a complex problem domain... How complete is the work you've done? The slang_execute_x86.c is fully functional, although it does not have any optimization. It is 10 x faster than the interpreter, so it is enough for now, there are other priorities. Are there any glaring problems with using the assembler, or things that should be changed? Let me know if there's anything I can clarify or help with... I have spotted some minor bug in the rtasm (see comments in the slang_execute_x86.c). Also I need literal arguments for some opcodes (PUSH, TEST) and 8-bit jumps. I can add this myself, but not as elegant as you can. -- Pozdrawiam, Michal Krol --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] GLSL status in Mesa
06-02-15, Brian Paul [EMAIL PROTECTED] napisał(a): I'm going to check in some fixes for warnings in the new code (nested comments, missing switch/default clauses, etc.). I'd also like to run the code through 'indent' to make the style match the rest of Mesa (3-space indentation etc). I've got other things going on this week so I'll try to look at the new code in more detail next week. Please dont. I will take care of it. I checkout the cvs once a week and work on it off-line. If you do some massive changes I would have to resolve massive conflicts or loose full week waiting for your changes. When I am finished, you can do your job, sure. -- Pozdrawiam, Michal Krol
Re: [Mesa3d-dev] GLSL status in Mesa
2006/2/15, Keith Whitwell [EMAIL PROTECTED]: Two questions: Firstly, I'm just looking at the shaders/slang directory now. How much of the C++ code in there is required for your compiler/assembler? It seems like from what is said above that your code is independent of the 3dlabs code, but they're currently located together in the mesa tree. Is there currently any dependency at all, and if so what? There are no dependencies at all. It was committed with the hope it will compile and run smoothly. It did not, so it is abandoned for now. Possible dependencies may be created in the future with the slang_assemble*.c files, and at least with the shaderobjects_3dlabs.c. Secondly, and please don't take offence - I don't really know much about how email formatting works, but for some reason your emails are very hard to read - very small font and very long, non-wrapped lines, and finally a string of garbage at the end of your signature. Probably some of this is my mail reader not coping with the character set you write in, but would it be possible to wrap your emails at some reasonable length and (for mail to the list) if it's easy to do, consider using a character set that is commonly installed on other peoples machines? Now I see the garbage too. Maybe my signature at the end causes it. Do you see the garbage now, when I replaced nonstandard letters? And to the long lines, I wrap very tightly. They seem to be concatenated again by some automata. I dont have the influence on this. It happened recently. Sorry. -- Pozdrawiam, Michal Krol --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Re: Help with Vertex Program execution in the interpreter
2006/2/14, Peter [EMAIL PROTECTED]: the function _mesa_exec_vertex_program in the shader/nvvertexec.c file never seems to get execute when running the vp-tris program in the /progs/vp folder. I've run DDD on it and something gets executed from the glutMainLoop. I've stepped through the code and I'm not seeing how the information that is stored when the ARB_Vertex_program is parsed gets used. Do you have any insight into why this is? The ARB vertex program gets executed in t_vb_arbprogram.c. NV and ARB vertex programs shared the nvvertexec.c for some time but not any more, it seems. -- Pozdrawiam, Michał Król
Re: [Mesa3d-dev] ARB_vertex_shader tnl
06-02-12, Keith Whitwell [EMAIL PROTECTED] napisał(a): Michał Król wrote: Hello, I am planning to enable ARB_vertex_shader in Mesa.FWIU, I must add a new stage in the tnl module.Done, dont see the results.Added conditions in other stages that are replacedby vertex shaders. Still I see black screen. Is your code being run? Try running gdb, breaking in _tnl_run_pipeline and stepping through the code to see what's happening. What other source files, besides t_vb_*.c, shouldI be aware of to have vertex shader running? As long as the new stage is in the pipeline, that should be enough (for tnl). OK. It is working. Thanks. Also, I am not sure with the tnl attrib indexes.What is the diferrence between VERT_ATTRIB_*,VERT_RESULT_ and _TNL_ATTRIB_* index flavours?Are the attrib indices generic and sharedamong all vertex-programming models? The TNL_ATTRIB_* bits are a superset of VERT_ATTRIB bits and are used throughout the pipeline. The VERT_RESULT_ bits aren't really used except in the existing vertex-program stages, and they are translated away straight away. This should change so that mesa's pipeline better matches what is specified in the vertex and fragment program extensions. Thanks. I just got confused after looking at vertex-program stages - lots of data movement using different indices. The only result left is the gl_ClipVertex. I suspect I should use it to perform user-clipping. I am not sure it is identical to vertex-programs, but I will blind-copy it and when the results are bad, I will hit the mesa-dev then.. -- Pozdrawiam, Michał Król
[Mesa3d-dev] ARB_vertex_shader tnl
Hello, I am planning to enable ARB_vertex_shader in Mesa. FWIU, I must add a new stage in the tnl module. Done, dont see the results. Added conditions in other stages that are replaced by vertex shaders. Still I see black screen. What other source files, besides t_vb_*.c, should I be aware of to have vertex shader running? Also, I am not sure with the tnl attrib indexes. What is the diferrence between VERT_ATTRIB_*, VERT_RESULT_ and _TNL_ATTRIB_* index flavours? Are the attrib indices generic and shared among all vertex-programming models? -- Pozdrawiam, Michał Król
[Mesa3d-dev] math functions
Mesa uses its own replacement functions for C library functions.
I need to use the following missing functions:
float asin (float);
float atan (float);
Should I use the clib functions directly, or there is someone
who takes care of it and who assures compatibility across
different platforms and compilers?
Maybe I should just make simple _mesa_* wrappers in imports.h
and if some problems occur, they are fixed in one central place?
--
Pozdrawiam,
Michał Król
NŹHYŢľéXŹ˛'˛ŢuźŚ[§Ü¨ş
ŢŚŘk˘č! WŹ~éŽĺzkśCŁ [EMAIL PROTECTED],şˇâ a{
ĺ,ŕHňÔ4¨mś˙ąéZ˛ë jYwţÇĽrg
Re: [Mesa3d-dev] Capturing 3D geometries
2006/1/16, Michael Frumin [EMAIL PROTECTED]:
I am attempting to capture 3D geometries from OpenGL applications for re-use
[...]
1) Would the Mesa code for
compiling/interpreting/evaluating vertex programs against a
set of vertices be easily re-usable by my DLL proxy?
If you want to simply isolate the vertex program subsystem from
the mesa sources, I think it could be easily done.
At least, the parsing part, which in fact has been developed
independent to the mesa project.
The executor part should also be ok. I havent looked at the
sources for years, but I think it is matter of redirecting
the inputs and outputs.
--
Pozdrawiam,
Michał Król
NŹHYŢľéXŹ˛'˛ŢuźŚ[§Ü¨ş
ŢŚŘk˘č! WŹ~éŽĺzkśCŁ [EMAIL PROTECTED],şˇâ a{
ĺ,ŕHňÔ4¨mś˙ąéZ˛ë jYwţÇĽrg
