what people who are
working on related things think about this (CCed them).
In particular, Zack Rusin has worked extensively with LLVM and I think
a prototype OpenCL implementation.
From the compute support LLVM-TGSI translation isn't even about
optimizations, it's about working. Writing a full
On Saturday 03 April 2010 18:58:36 Marek Olšák wrote:
On Sun, Apr 4, 2010 at 12:10 AM, Zack Rusin
za...@vmware.commailto:za...@vmware.com wrote: I thought the initial
proposal was likely a lot more feasible for a GSOC (of course there one
has to point out that Mesa's GLSL compiler already
On Saturday 03 April 2010 19:07:59 Luca Barbieri wrote:
Gallium. Obviously a code-generator that can handle control-flow (to be
honest I'm really not sure why you want to restrict it to something
without control- flow in the first place).
The no-control-flow was just for the first step,
On Tuesday 30 March 2010 12:52:54 Luca Barbieri wrote:
There are several deep challenges in making TGSI - LLVM IR translation
lossless -- I'm sure we'll get around to overcome them -- but I don't
think that using LLVM is a requirement for this module. Having a shared
IR for simple TGSI
On Thursday 11 March 2010 02:58:49 Tollef Fog Heen wrote:
]] Zack Rusin
| BTW, replacing a mail client on the server with something that's not
| compatible is not very social.
Rather than assuming malice, you may assume that I was trying to fix
something when I made that change.
I
On Wednesday 10 March 2010 13:59:40 Brian Paul wrote:
Brian Paul wrote:
Keith Whitwell wrote:
I haven't seen any of these for a while now... Anyone have any ideas?
I haven't seen them either. I don't know what's going on, but Tollef
Fog Heen (an FD.org admin) created new mesa lists on
On Wednesday 10 March 2010 15:18:03 Zack Rusin wrote:
On Wednesday 10 March 2010 14:59:42 Zack Rusin wrote:
Maybe /usr/bin/mail is broken, I'll double check it.
Yea, that's it. Someone installed a new mail daemon on the server. We're
using -a to specify the Content-Type header in mails
On Wednesday 03 March 2010 10:51:13 o...@lunarg.com wrote:
From: Chia-I Wu o...@lunarg.com
When the paint is color, paint_bind_samplers binds a dummy sampler
without a texture. It causes demos requiring a sampler (those use a
mask or an image) to crash.
---
On Wednesday 03 February 2010 09:19:43 Igor Oliveira wrote:
A new version and a little improvement.
Makes more sense adding the texture in paint bind samplers than mask
bind samplers.
Igor
On Wed, Feb 3, 2010 at 6:21 AM, Igor Oliveira
igor.olive...@openbossa.org wrote:
This patch fix
On Monday 01 February 2010 10:19:53 Igor Oliveira wrote:
Hello,
Theses patchs switch all shaders code implemeted using TGSI assembly
by tgsi_ureg.
Hey Igor,
very nice work!
Since I don't have the conformance framework anymore, did you test your
changes with the examples that we have?
On Monday 01 February 2010 21:28:53 Igor Oliveira wrote:
Hi again,
Third version: removing debug messages
Nicely done, I just committed the patches. Thanks!
(a small nitpick, in future try to be a bit more descriptive in your commit
log :) ).
z
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 blending
962994ad9f05b6ae219f839082d4743e7d2a70fe Mon Sep 17 00:00:00 2001
From: Zack Rusin z...@kde.org
Date: Mon, 11 Jan 2010 12:34:26 -0500
Subject: [PATCH] gallium: implement feature levels
a broader way of figuring out features of the hardware we're running on
---
src/gallium/docs/source/gallium_feature_levels.rst | 69
On Monday 11 January 2010 15:17:00 Roland Scheidegger wrote:
- extra mirror wrap modes - i don't think mirror repeat was ever
supported and mirror clamp was removed in d3d10 but it seems that some
hardware kept support for those
Mirror repeat is a core feature in GL since 1.4 hence we
On Monday 11 January 2010 15:22:43 Luca Barbieri wrote:
The feature levels in the attached table don't apply exactly to all
hardware.
For instance:
1. Two sided stencil is supported from NV30/GeForce FX
2. Triangle fans and point sprites are supported in hardware on NV50
(according to
On Monday 11 January 2010 16:15:38 Jakob Bornecrantz wrote:
On 11 jan 2010, at 17.49, Zack Rusin wrote:
I think the other stuff is acceptable. Take a look at the docs and
let me know
what you think.
Hmm I don't think you should remove the CAPs but instead just say if
level X then CAPs Y
On Monday 11 January 2010 18:04:01 Michel Dänzer wrote:
A better fix should be to make sure the exaMoveInPixmap() call is before
the exaGetPixmapDriverPrivate() call. The latter should never return
NULL then (unless we run out of resources maybe - might be worth keeping
the checks for that).
On Monday 11 January 2010 18:18:30 Michel Dänzer wrote:
On Mon, 2010-01-11 at 18:05 -0500, Zack Rusin wrote:
On Monday 11 January 2010 18:04:01 Michel Dänzer wrote:
A better fix should be to make sure the exaMoveInPixmap() call is
before the exaGetPixmapDriverPrivate() call. The latter
On Thursday 07 January 2010 06:50:36 José Fonseca wrote:
I wonder if storage size of registers is such a big issue. Knowing the
storage size of a register matters mostly for indexable temps. For
regular assignments and intermediate computations storage everything
gets transformed in SSA form,
On Thursday 07 January 2010 09:11:11 michal wrote:
Zack,
1. Do I understand correctly that while
D_ADD dst.xy, src1.xy, src2.zw
will add one double, is the following code
D_ADD dst, src1, src2.zwxy
also valid, and results in two doubles being added together?
Good question. I guess
On Wednesday 06 January 2010 14:56:35 Igor Oliveira wrote:
Hi,
the patches add support to double opcodes in gallium/tgsi.
It just implement some opcodes i like to know if someone has
suggestion about the patches.
Hi Igor, first of all this should probably go into a feature branch because
On Friday 01 January 2010 06:42:18 Corbin Simpson wrote:
Couple things.
First, if we're going to start autogenerating headers, can we do GL
API first?
As long as we first fix the Exchange integration in KMail (i.e. it's a bit
unfair to bring up mysterious unrelated features as a problem
On Saturday 26 December 2009 02:19:40 Marek Olšák wrote:
Zack,
to be honest, Direct3D 11 can report geometry shaders are not supported
through so-called feature levels. There are six levels to my knowledge
(9_1, 9_2, 9_3, 10_0, 10_1, 11_0). i915 is 9_1, R300 is 9_2, R500 is 9_3,
and so
On Friday 25 December 2009 07:03:02 Corbin Simpson wrote:
Isn't this incredibly at odds with our previous discussion, in which
we generally agreed to not advertise support for unaccelerated things?
No, it's really not. We don't have caps for core features, e.g we don't have
caps for vertex
the entire series.
z
From 0483e3ed1c28982857da3292f8247388e8f9d0d9 Mon Sep 17 00:00:00 2001
From: Zack Rusin za...@vmware.com
Date: Thu, 24 Dec 2009 09:20:45 -0500
Subject: [PATCH 13/15] util: put vertices_per_primitive function in its proper location
---
src/gallium/auxiliary/tgsi/tgsi_sanity.c
On Thursday 24 December 2009 10:03:25 Keith Whitwell wrote:
Thanks Zack. I'm fine with doing it on top of the others...
ok, great, thanks Keith. In that case I'll wait for any objections until
tomorrow and if nothing will show up commit in the morning.
z
The attached patch makes the tgsi assembly parser report, in an admittedly
rather crude way, the line number at which a syntax error was detected. What
do you think about that?
z
From 7a7784d69ebf6a8b16386821217a5af232213cbc Mon Sep 17 00:00:00 2001
From: Zack Rusin za...@vmware.com
Date: Tue
On Tuesday 15 December 2009 09:21:05 michal wrote:
Zack Rusin pisze:
The attached patch makes the tgsi assembly parser report, in an
admittedly rather crude way, the line number at which a syntax error was
detected. What do you think about that?
I agree, that's a bit invasive.
What
On Tuesday 15 December 2009 09:27:04 Keith Whitwell wrote:
On Tue, 2009-12-15 at 06:12 -0800, Zack Rusin wrote:
The attached patch makes the tgsi assembly parser report, in an
admittedly rather crude way, the line number at which a syntax error was
detected. What do you think about
On Monday 14 December 2009 09:29:03 Keith Whitwell wrote:
On Mon, 2009-12-14 at 06:23 -0800, michal wrote:
To fully support geometry shaders, we need some means to declare a
two-dimensional register file. The following declaration
DCL IN[3][0]
would declare an input register with
On Friday 11 December 2009 08:05:24 michal wrote:
There's gs_instance_id which specifies the id of the instance of the
geometry shader (which is different than the global draw instance).
There's also the number of vertices that the geometry shader works on (1
points, 2 lines, 3 triangles,
On Thursday 10 December 2009 16:26:33 Younes Manton wrote:
On Thu, Dec 10, 2009 at 3:34 PM, Zack Rusin za...@vmware.com wrote:
On Thursday 10 December 2009 15:14:46 Younes Manton wrote:
OK, so we seem to be on the same page here, pipe_context will get some
more functions. That's what I
On Wednesday 09 December 2009 20:30:56 Igor Oliveira wrote:
Hi Zack,
1) agreed. OpencCL is a complete different project and should exist in
a different repository.
1.1) Well use Gallium as CPU backend is a software dilemma:
All problems in computer science can be solved by another level of
On Thursday 10 December 2009 11:25:48 Younes Manton wrote:
On Thu, Dec 10, 2009 at 5:32 AM, Zack Rusin za...@vmware.com wrote:
On Wednesday 09 December 2009 20:30:56 Igor Oliveira wrote:
Hi Zack,
1) agreed. OpencCL is a complete different project and should exist in
a different
On Thursday 10 December 2009 14:35:47 Younes Manton wrote:
Well how do we keep the compute state seperate from the 3D state, and
how do you mix the two?
It's really the same state. You bind a compute shader and execute it. It
doesn't affect the rest of your state. Compute binds the buffers
On Thursday 10 December 2009 15:14:46 Younes Manton wrote:
OK, so we seem to be on the same page here, pipe_context will get some
more functions. That's what I was originally asking about, will
pipe_context grow or will there be a new kind of context? From my POV
we would end up in roughly the
Hi,
currently Gallium3d shaders predefine all their inputs/outputs. We've handled
all inputs/outputs the same way. e.g.
VERT
DCL IN[0]
DCL OUT[0], POSITION
DCL OUT[1], COLOR
DCL CONST[0..9]
DCL TEMP[0..3]
or
FRAG
DCL IN[0], COLOR, LINEAR
DCL
On Wednesday 09 December 2009 08:44:20 Keith Whitwell wrote:
On Wed, 2009-12-09 at 04:41 -0800, michal wrote:
Zack Rusin pisze:
Hi,
currently Gallium3d shaders predefine all their inputs/outputs. We've
handled all inputs/outputs the same way. e.g.
VERT
DCL IN[0]
DCL OUT[0
On Wednesday 09 December 2009 07:41:11 michal wrote:
Zack Rusin pisze:
Hi,
currently Gallium3d shaders predefine all their inputs/outputs. We've
handled all inputs/outputs the same way. e.g.
VERT
DCL IN[0]
DCL OUT[0], POSITION
DCL OUT[1], COLOR
DCL CONST[0..9]
DCL TEMP[0..3
On Wednesday 09 December 2009 08:55:09 michal wrote:
Zack Rusin pisze:
On Wednesday 09 December 2009 08:44:20 Keith Whitwell wrote:
On Wed, 2009-12-09 at 04:41 -0800, michal wrote:
Zack Rusin pisze:
Hi,
currently Gallium3d shaders predefine all their inputs/outputs. We've
handled
On Wednesday 09 December 2009 10:05:13 michal wrote:
Zack Rusin pisze:
On Wednesday 09 December 2009 08:55:09 michal wrote:
Zack Rusin pisze:
On Wednesday 09 December 2009 08:44:20 Keith Whitwell wrote:
On Wed, 2009-12-09 at 04:41 -0800, michal wrote:
Zack Rusin pisze:
Hi
On Wednesday 09 December 2009 10:18:42 Zack Rusin wrote:
I could do that but only if we agree it's in the name of love.
So is everyone ok with a new register SV for system generated values and
new declaration token called PROPERTY for shader specific properties (btw,
d3d calls those
On Wednesday 09 December 2009 13:29:05 Igor Oliveira wrote:
These patchs implements and implements stub context methods in OpenCL.
Almost all operation in OpenCL use a context.
The patch implements the gallium3d context and implements the methods
below:
-clCreateContext
On Wednesday 09 December 2009 15:07:45 michal wrote:
Keith Whitwell pisze:
On Wed, 2009-12-09 at 10:19 -0800, Keith Whitwell wrote:
On Wed, 2009-12-09 at 07:18 -0800, Zack Rusin wrote:
On Wednesday 09 December 2009 10:05:13 michal wrote:
Zack Rusin pisze:
On Wednesday 09 December 2009
On Thursday 19 November 2009 16:11:28 Ian Romanick wrote:
2. The Intel team is only just switching from feature development mode
to bug fixing mode. There is a giant pile of bugs that exist in both
7.6 and master. At least some of those will get fixed over the next few
weeks. If we rush
On Sunday 15 November 2009 22:03:27 Igor Trindade Oliveira wrote:
Hi Zack,
Would be great.
Other thing that i was checking is about the egl state tracker, and
softpipe in embedded. normally egl is used in embedded environments but
mesa uses lot of float points and sse operations. It could
On Saturday 24 October 2009 19:02:51 Younes Manton wrote:
Hi Thomas,
I'd like to make these changes to make it possible to use the DRM
state tracker interface with contexts other than pipe_context. Nouveau
is the only public driver that does DRI1 from what I can see, but I've
been told that
On Thursday 01 October 2009 14:13:15 Greg KH wrote:
Hi,
As discussed at XDC2009 in your talk about patents and xorg, I talked
with the Linux Foundation's Technical Advisory board about the issues
your raised in your talk.
I have a contact at the LF and OIN to put you in contact with, but
On Sunday 27 September 2009 22:30:00 Younes Manton wrote:
Ok I just pushed this all out and moved xvmc under xorg.
state_trackers/g3dvl is now completely useless and I'll delete it
soon.
pipe_video_context and vl_compositor still need some love for Xv and
more love for VDPAU.
Nice work.
On Tuesday 22 September 2009 14:10:34 Jakob Bornecrantz wrote:
diff --git a/src/gallium/state_trackers/xorg/xorg_composite.c
b/src/gallium/state_trackers/xorg/xorg_composite.c index 66ca4cb..ed649a9
100644
--- a/src/gallium/state_trackers/xorg/xorg_composite.c
+++
Hey,
I'm going to start adding XvMC acceleration to the Gallium's xorg state
tracker.
I'd like to move src/xvmc to src/gallium/state_trackers/xorg/xvmc and run the
standard Mesa3D indent command on both g3dvl and xvmc.
I'm by no means saying that the style in them is bad, or that any style is
On Monday 14 September 2009 14:04:54 Brian Paul wrote:
in general though none of those should be too difficult to fix, but it'd
be a good idea to figure out if we want geometry shaders in 7.7 or 7.8.
as always with large patches that touch a lot of the code, keeping up to
date with master
hey,
i've been playing around with geometry shaders in my spare time and finally got
them to a basically working state. basically working implies a high
likelihood of many bugs, but bugs that i'd like to get fixed for 7.7 or the
very latest 7.8. so i'd like to merge arb_geometry_shaders4 as
On Friday 04 September 2009 05:08:48 Keith Whitwell wrote:
On Thu, 2009-09-03 at 15:13 -0700, Michel Dänzer wrote:
On Thu, 2009-09-03 at 14:43 -0700, Ian Romanick wrote:
2. It becomes increasing difficult to merge (as opposed to cherry-pick)
from one branch to the other as the branches
On Thursday 20 August 2009 15:13:01 Nicholas Lowell wrote:
When attempting to draw a box with the attached code, this OpenVG
implementation does not produce expected results as the Khronos
implementation does.
Suspected area of issue is either improper translation of (ox, oy) during
vgRotate
On Monday 24 August 2009 11:31:29 Zack Rusin wrote:
On Thursday 20 August 2009 15:13:01 Nicholas Lowell wrote:
When attempting to draw a box with the attached code, this OpenVG
implementation does not produce expected results as the Khronos
implementation does.
Suspected area of issue
On Monday 17 August 2009 12:41:55 Andreas Pokorny wrote:
Hello,
2009/8/16 Zack Rusin za...@vmware.com:
[...]
Yes, the code required to actually read/rasterize and render glyphs is
missing. So basically the entire api_text.c would need to be implemented.
What's in there was basically
On Saturday 15 August 2009 22:26:32 Maarten Maathuis wrote:
- PIPE_TRANSFER_READ ended up being defined as 0, which is obviously fail.
I'm not sure I understand, what's wrong with that?
--
Let Crystal Reports handle the
On Sunday 16 August 2009 07:18:13 Andreas Pokorny wrote:
Hi there,
I saw that the openvg state tracker already implements version 1.1 The
code is only deactivated by the OpenVG main API header provided in the
master branch. Is there anything missing in the implementation?
Yes, the code
On Sunday 16 August 2009 17:22:37 Maarten Maathuis wrote:
On Sun, Aug 16, 2009 at 9:03 PM, Zack Rusinza...@vmware.com wrote:
On Saturday 15 August 2009 22:26:32 Maarten Maathuis wrote:
- PIPE_TRANSFER_READ ended up being defined as 0, which is obviously
fail.
I'm not sure I understand,
On Sunday 16 August 2009 18:00:05 Maarten Maathuis wrote:
Any special value on calling it an enum (debugging maybe?) instead of
a few defines?
Yea, debugging is one of the main reasons. Others are the extra type-safety
they give us and the clarity of what values go where.
We've been trying to
On Saturday 25 July 2009 05:52:01 Nicolai Hähnle wrote:
Am Saturday 25 July 2009 05:15:13 schrieben Sie:
I'm not sure I understand what you mean by stream-based nature of TGSI.
It's just just an array of struct tgsi_token's. So technically you could
iterate from the back, middle, 2+middle
On Friday 24 July 2009 13:33:22 José Fonseca wrote:
To be honest I don't think that using LLVM from C for our purposes is a
good idea. Mainly because it will be impossible to do because backends
(the actual code-generators for given hardware) will need to be C++
anyway so we'll again end
On Friday 24 July 2009 14:21:35 José Fonseca wrote:
But in this step 1 you don't plan to embed the vector width and AoS vs
Soa in TGSI, right?
No, nothing changes at that layer.
Essentially LLVM is completely invisible to drivers and TGSI representation
stays exactly the same.
Everything is
On Friday 24 July 2009 15:40:25 Keith Whitwell wrote:
I think a fast software rasterizer project would be better described as
create a gallium driver targetting LLVM (as opposed to optimizing
softpipe), as softpipe fills a pretty useful niche in its current form.
Thinking of LLVM as the
On Friday 24 July 2009 20:00:16 Anders Juel Jensen wrote:
On Friday 24 July 2009 21:40:25 Keith Whitwell wrote:
Thinking of LLVM as the hardware has a couple of positive
psychological implications -- most importanly that we are in the
business of programming LLVM to do rasterization, rather
On Friday 24 July 2009 20:25:19 Nicolai Hähnle wrote:
Most importantly and crucially, the stream-based nature of TGSI is, in my
opinion, harmful. Essentially, it forces one to use only forward-scan-based
algorithms that look at one single instruction at a time.
I'm not sure I understand what
On Thursday 23 July 2009 12:59:49 Keith Whitwell wrote:
Module: Mesa
Branch: master
Commit: adc6f8cdfc8ca25d7480a50cfe0f85fdeddbfcfc
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=adc6f8cdfc8ca25d7480a50cfe
0f85fdeddbfcfc
Author: Keith Whitwell kei...@vmware.com
Date: Thu Jul
On Thursday 23 July 2009 13:58:54 Keith Whitwell wrote:
OK. I wanted to fix any breakages from my recent changes, so
trivial/tri is at least running now.
BTW - I don't think this should be removed from master - there are a lot
of people just waiting to get a bit of time to work on this,
On Friday 17 July 2009 15:47:07 Nicholas Lowell wrote:
I pulled the revision just before eglcurrent.c/.h was introduced (because
that is saying it can't find eglcurrent.c/.h, feel free to help with that
issue) and 'make linux-x86-debug'dir li with EGL_DRIVER=egl_softpipe
works. But this is
On Thursday 16 July 2009 17:09:47 Nicholas Lowell wrote:
make linux-x86: behaves like make linux
Hmm, that's interesting. For me
make linux-x86
cd src/gallium/state_trackers/vega
make
cd ../../../../progs/openvg/demos/
make
EGL_DRIVER=egl_softpipe ./lion
just works. Can you do a make
On Sunday 14 June 2009 20:29:47 tom fogal wrote:
My application was failing because we were creating floating
point textures. We would get an INVALID_VALUE by specifying a
ARB_texture_float internal format for glTexImage2D.
The attached two-line diff enables the extension, and my app gets by
Hi,
as mentioned yesterday the OpenVG state tracker is now in the repository.
It's a complete implementation of OpenVG 1.0. Every feature of the standard
should work.
It's under the same BSD license as Mesa3D.
docs/openvg.html contains instructions on how to build it.
Just like the Mesa's
Hey,
so that it doesn't come as such a huge surprise we wanted to let everyone know
that we'll be releasing some new code that hopefully we'll make a lot of
people happy.
We'll start with an OpenVG 1.0 state tracker for Gallium tomorrow.
The new code will live temporarily in branches to not
On Thursday 09 April 2009 14:03:20 Ian Romanick wrote:
Stephane Marchesin wrote:
That's my point: video codecs move too fast to be put into silicon,
and require too many resources to implement. So we should use shaders
and lay everything onto an API that takes care of the hardware
On Wednesday 11 March 2009 09:41:08 Kamalneet Singh wrote:
Brian Paul wrote:
Kamalneet Singh wrote:
Stephane Marchesin wrote:
[...]
What specifically are you interested in ? FWIW all this stuff is quite
unfinished...
We have a project to develop OpenGL ES Shading Language compiler.
On Tuesday 06 January 2009 16:00:48 keithw wrote:
On Tue, 2009-01-06 at 04:26 -0800, PLUG GULP wrote:
I think if it is limited to using EC++ then that will act as a guideline
too.
~Plug.
On Tue, Jan 6, 2009 at 12:33 AM, Zack Rusin za...@vmware.com wrote:
On Monday 05 January 2009
On Monday 05 January 2009 17:23:40 Ian Romanick wrote:
2. Linking with C++ libraries causes problems with applications.
So far, a fair portion of my GLSL compiler work has been re-creating a
C++-like object heirarchy and management system. Frankly, the code
would be much better (for all
On Wednesday 31 December 2008 09:15:09 Alex wrote:
Zack Rusin wrote:
I think Alex was referring here to a AOS layout which is completely not
ready.
Actually currently the plan is to have essentially a two pass LLVM IR.
I wanted the first one to never lower any of the GPU instructions so
On Tuesday 30 December 2008 11:05:34 Alex wrote:
Hello.
I am very new to this mailing list so if I've missed something please
nicely point it out.
I am reading the source code of the Mesa Cell driver (branch gallium-0.2)
and get really confused.
If I read correctly, there are two paths
On Tuesday 30 December 2008 15:30:35 Chris Lattner wrote:
On Dec 30, 2008, at 6:39 AM, Corbin Simpson wrote:
However, the special instrucions cannot directly be mapped to LLVM
IR, like
min, the conversion involves in 'extract' the vector, create
less-than-compare, create 'select'
On Monday 24 November 2008 16:32:24 PLUG GULP wrote:
Thanks for trying git+http for mesa repository.
What you can also try is simply downloading:
http://people.freedesktop.org/~zack/mesa.tar.bz2
which is a tar.bz2 of an Mesa http anongit repo. Once you get and untar it, it
should work like a
On Monday 10 November 2008 16:48:49 Pekka Paalanen wrote:
It looks somehow wrong, and to get it in
Is there anything in specific that looks wrong with it? It looks right to me.
line with the rest of the code, I propose this fix.
It looks to me like you did the opposite versus the other
On Tuesday 30 September 2008 14:21:10 Stephane Marchesin wrote:
Hi again,
I've adapted (but didn't push it) gallivm to llvm 2.4 (svn) API
changes. But then there's an obvious question about what we're doing
with those API changes ? Do we settle on a given version, or do we
want to adapt it
On Sunday 28 September 2008 14:34:53 Stephane Marchesin wrote:
Hi,
I'm working on llvm integration in gallium,
Ah, that's great.
but I have a small problem
with the current design. Basically, the tgsi to llvm translator
currently generates calls to library functions (abs(), exp(), log(),
On Sunday 28 September 2008 15:04:42 Stephane Marchesin wrote:
Oh, I'm thinking about doing driver-specific llvm backends here.
Yea, that was always my plan.
I've realised that the difference between GPUs really didn't allow common
intermediate representation. Furthermore, the llvm tablegen
Hey,
I just realized this was never communicated so just a quick note. Keith, Alan
and Brian did the bulk of the work to get gallium-0.1 merged with master and
the result is gallium-0.2 branch.
It's essentially gallium3d on top of master. gallium-0.2 should stay in sync
with master from now
Hey,
I've replaced the script we've been using for the Mesa Git repo with a modified
version of the script used by the Wine guys.
Basically the differences are as following:
1) If the push has less than 20 commits then they will be sent as individual
emails
2) Each one of the individual
On Sunday 21 September 2008 19:26:46 Zack Rusin wrote:
commiting try to have : a) first line of the commit message description of
what it does, b) a newline and description of what it does
*why*
so:
first line) what it does
second line) empty
third line) why it does
On Thursday 05 June 2008 12:47:07 am Dave Airlie wrote:
Gallium might ultimately wind up in its own repository as a stand-alone
project. Afterall, Gallium drivers could be used by APIs other than
OpenGL.
The question is mainly from a distro point of view what do we need to ship
a gallium
On Friday 15 February 2008 08:43:08 Keith Whitwell wrote:
Basically I've just made a start on this - shifting things into separate
files where previously they were all jammed together.
Wicked. It's definitely something I wanted to see for the longest time!
Unfortunately I haven't been able to
On Wednesday 19 December 2007 09:20:06 am Matthias Hopf wrote:
On Dec 19, 07 06:07:15 -0800, Dan Nicholson wrote:
I'm not sure what we'd gain in exchange for losing history. At the very
least, I think such branches should be preserved in a separate
legacy/history repository.
I guess
On Tuesday 11 December 2007 03:50:44 pm Brian Paul wrote:
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
This patch ports the existing Gallium Cell code to use libspe2 instead
of libspe. libspe is deprecated in SDK 2.1 and is removed from SDK
On Saturday 01 December 2007 06:12:45 am Eli Friedman wrote:
Patch to fix building the linux-llvm target of gallium3d.
There are essentially two groups of fixes here: one is fixing the
includes to match a recent header reorganization, and the other is
making it build against trunk LLVM, where
On Monday 19 November 2007 12:13:24 pm Ian Romanick wrote:
I'm trying to build linux-llvm on PowerPC, but it seems that
TGSI_OPCODE_TXP isn't defined anywhere. Did someone forget to push a
commit?
To some extend. Brian removed it (with TGSI semantics TXP was really TEX with
On Sunday 16 September 2007 02:41:24 pm Keith Whitwell wrote:
1) Fewer state objects, probably 5 or 6.
2) The constant state object life cycle, ie:
- CreateBlendState
- BindBlendState
- DestroyBlendState
3) State partitioned in a hopefully sensible way for hardware.
The
On Friday 18 May 2007 01:53:53 pm Ian Romanick wrote:
Yeah, that's where Roberto came in :) We used QLALR which is simply
amazing and for those who ever used Bison a lot more convenient than what
we had right now.
http://labs.trolltech.com/page/Projects/Compilers/QLALR
Initially we
On Monday 21 May 2007 03:11:28 pm Keith Whitwell wrote:
It seems that either the LLVM IR would need some extensions for those
things or the back-end code generator/instruction selector would have to
look for patterns of scalar instructions and figure out where vector ops
should be used.
On Thursday 17 May 2007 05:36:45 pm Keith Whitwell wrote:
I think the Zack/Roberto LLVM tree has done just this. Unfortunately
for this immediate problem, they target a whole new intermediate
representation.
Zack, what tools did you use for the front-end/parser? I've been
looking
On Tuesday 15 May 2007 06:29:43 am Keith Whitwell wrote:
Of particular interest to us is the runtime code generator and shader
compiler. We have been developing something we're calling the Tungsten
Graphics Shader Infrastructure, which is intended to be a retargetable
compiler for GLSL and
100 matches
Mail list logo
