These were previously being left in the default (D3D) mode. This mean
that triangles were drawn slightly incorrectly, but also because this
state is relied on by the u_blitter code, all blits were half a pixel
off.
---
src/gallium/drivers/r600/r600_state.c |5 +
src/gallium/driver
On Tue, Nov 2, 2010 at 7:54 PM, Alex Deucher wrote:
> On Tue, Nov 2, 2010 at 3:40 PM, Keith Whitwell wrote:
>> These were previously being left in the default (D3D) mode. This mean
>> that triangles were drawn slightly incorrectly, but also because this
>> state is relie
Looks good Tillman.
Keith
On Tue, Nov 2, 2010 at 9:17 PM, Tilman Sauerbeck wrote:
> Signed-off-by: Tilman Sauerbeck
> ---
>
> v2: Also call into the pipe driver to make it release its reference.
>
> src/mesa/state_tracker/st_context.c | 5 +
> 1 files changed, 5 insertions(+), 0 deletio
Looks good, committed. Thanks for fixing this.
Keith
On Wed, Nov 3, 2010 at 9:14 PM, Guillermo S. Romero
wrote:
> Commit 8dfafbf0861fe3d2542332658dd5493851053c78 forgot to update r300g.
> There is a buf == NULL check, but buf is used before for var init.
>
> Tested-by: Guillermo S. Romero
> --
Michal - it looks like this will mean that these tests now always try to create
& populate a "result.bmp" file? Would it be possible to guard this behaviour
with some sort of option, eg an environment var?
Keith
From: mesa-dev-bounces+keithw=vmware@l
There is still more to do there. Currently r600g treats buffer and texture
uploads separately, and I've only attempted to improve texture uploads. Buffer
is just as important however.
The change needed is likely to be one of two:
a) Allow newly created vertex buffers to be in the GTT domain, w
On Thu, 2010-11-11 at 14:59 -0800, Jerome Glisse wrote:
> 2010/11/11 Keith Whitwell :
> > There is still more to do there. Currently r600g treats buffer and texture
> > uploads separately, and I've only attempted to improve texture uploads.
> > Buffer is just as impo
On Fri, 2010-11-12 at 20:32 -0800, Jerome Glisse wrote:
>
> I think r600c is just a bit too naive and so it end up being very
> expensive to change any states with it. But i haven't took a closer
> look. I don't think we should look too much at relative cost of
> changing state. I think fglrx opt
On Sun, 2010-11-14 at 20:18 -0800, Dave Airlie wrote:
> Eric just checked in a test into piglit that tests that the
> gl_FragCoord works the right way up for FBOs,
>
> Now all the gallium drivers fail this currently and fixing it creates
> an ugly linkage between the currently bound buffer and the
On Mon, 2010-11-15 at 01:28 -0800, Keith Whitwell wrote:
> On Sun, 2010-11-14 at 20:18 -0800, Dave Airlie wrote:
> > Eric just checked in a test into piglit that tests that the
> > gl_FragCoord works the right way up for FBOs,
> >
> > Now all the gallium drivers fail t
On Mon, 2010-11-15 at 01:32 -0800, Keith Whitwell wrote:
> On Mon, 2010-11-15 at 01:28 -0800, Keith Whitwell wrote:
> > On Sun, 2010-11-14 at 20:18 -0800, Dave Airlie wrote:
> > > Eric just checked in a test into piglit that tests that the
> > > gl_FragCoord work
On Mon, Nov 15, 2010 at 9:46 PM, Alex Deucher wrote:
> On Mon, Nov 15, 2010 at 4:41 PM, Tilman Sauerbeck
> wrote:
>> piglit/fbo-readpixels still passes for me.
>>
>> Signed-off-by: Tilman Sauerbeck
>> ---
>>
>> Please review. And someone please tell me where those 512 and 256 bytes
>> are comin
On Wed, 2010-11-10 at 16:04 -0800, Jakob Bornecrantz wrote:
> Hi all
>
> We have a bunch of redundant target helpers to wrap screens with debug
> drivers and for creating the various software drivers. This series removes
> all but the inline one, I picked it since it gives more flexibility for
On Tue, 2010-11-16 at 13:40 -0800, Roland Scheidegger wrote:
> On 16.11.2010 22:15, Jerome Glisse wrote:
> > On Tue, Nov 16, 2010 at 3:27 PM, Roland Scheidegger
> > wrote:
> >> On 16.11.2010 20:59, Jerome Glisse wrote:
> >>> On Tue, Nov 16, 2010 at 2:38 PM, Roland Scheidegger
> >>> wrote:
> >>>
On Mon, 2010-11-22 at 20:06 -0800, Dave Airlie wrote:
> Hi Marek,
>
> So I was looking at some perf traces from r600g, and I see a stall on
> the blitter quad vbuf, every clear will cause the CPU to block on the
> mapping of the vbuf to upload the new coords. On r300g I can see this
> not matterin
On Wed, 2010-11-24 at 18:28 -0800, Roland Scheidegger wrote:
> From:
> Roland Scheidegger
>
>To:
> mesa-dev@lists.freedesktop.org
> ,
> Keith Whitwell
> Subject:
> RFC: gal
On Tue, 2010-11-30 at 01:51 -0800, Chia-I Wu wrote:
> Hi list,
>
> I have spent the weekend adding OpenVG 1.1 support to Vega state
> tracker. The new features added include mask layer support, text
> support, and a new color transformation stage. The work can be found
> at
>
> http://cgit.fr
On Tue, 2010-11-30 at 18:07 -0800, Roland Scheidegger wrote:
> Am 30.11.2010 21:23, schrieb Ian Romanick:
> > It seems that new development in master has slowed a bit, so how does
> > a 7.10 release on January 7th sound? If we're going to do that,
> > we'll want to make the 7.10 branch on, say, De
On Sat, 2010-12-11 at 04:22 -0800, Jose Fonseca wrote:
> Looks good to me FWIW.
>
> Usually one uses a union for avoid breaking strict-aliasing rules, but your
> memcpy approach should produce just as good code with less typing.
>
> The only proper fix here would be to make struct tgsi_token an
On Mon, 2010-12-13 at 07:09 -0800, Brian Paul wrote:
> On 12/10/2010 03:27 PM, Vinson Lee wrote:
> > Module: Mesa
> > Branch: master
> > Commit: ef3f7e61b314236cbb7ed2cf24d34c6f90d9cfca
> > URL:
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=ef3f7e61b314236cbb7ed2cf24d34c6f90d9cfca
> >
>
Looks good to me.
Keith
On Tue, 2010-12-14 at 05:15 -0800, Marek Olšák wrote:
> ---
> src/gallium/auxiliary/os/os_thread.h | 51
> ++
> 1 files changed, 51 insertions(+), 0 deletions(-)
>
> diff --git a/src/gallium/auxiliary/os/os_thread.h
> b/src/gallium/aux
On Wed, 2010-12-15 at 09:19 -0800, Kristian Høgsberg wrote:
> On Wed, Dec 15, 2010 at 10:10 AM, Thomas Hellstrom
> wrote:
> ...
> > Given this, I would advise strongly against building spinlocks into any code
> > that might be run on a uni-processor system. Particularly gallium utility
> > code.
On Fri, 2010-12-17 at 00:49 -0800, Dave Airlie wrote:
> On Tue, Apr 27, 2010 at 7:10 AM, Dave Airlie wrote:
> buffers.
> >>> But you'll have more shader instructions for writing to all these
> >>> outputs right? I think that could still make a difference, though it
> >>> might be more theoret
Looks good, Marek.
Keith
On Sun, 2010-12-19 at 04:02 -0800, Marek Olšák wrote:
> ---
> src/gallium/auxiliary/util/u_index_modify.c | 12 ++--
> src/gallium/auxiliary/util/u_inlines.h |3 +--
> src/gallium/auxiliary/util/u_upload_mgr.c|4 ++--
> src/galliu
This promotes a private interface to a public one, right? If so that
isn't really doing us any favours as next people will complain when that
newly public interface varies between releases.
If you want to save disk space by sharing components, what about an
alternate approach -- investigate metho
Marek,
This series looks good to me.
Keith
On Tue, 2010-12-21 at 19:00 -0800, Marek Olšák wrote:
> And also check if the formats are supported to return something meaningful
> if compression cannot be used.
> ---
> src/mesa/state_tracker/st_format.c | 20
> 1 files change
Dave,
This all looks good to me (modulo the glitch Tilman pointed out).
Keith
On Thu, 2010-12-23 at 00:43 -0800, Dave Airlie wrote:
> For GL fragColor semantics we need to tell the pipe drivers that the fragment
> shader color result is to be replicated to all bound color buffers, this
> adds th
On Fri, Dec 24, 2010 at 4:12 AM, Christopher James Halse Rogers
wrote:
> On Tue, 2010-12-21 at 08:58 +0000, Keith Whitwell wrote:
>> This promotes a private interface to a public one, right? If so that
>> isn't really doing us any favours as next people will complain when
On Sat, 2011-01-29 at 15:12 -0800, Marek Olšák wrote:
>
>
> Hi,
>
> I am proposing to add a pointer to a user buffer in pipe_resource.
> There are two reasons for this:
>
> 1) I would like to have a way to query outside of a driver whether a
> buffer is a user buffer. Simply comparing the point
On Mon, 2011-01-31 at 10:46 -0800, Marek Olšák wrote:
> Hi Keith,
>
> From my point of view, user buffers are just pointers passed through
> the Gallium interface and are well-defined from what I can see. They
> might be owned by the application (e.g. set via glVertexPointer etc.),
> therefore usi
Keith
- Original Message -
From: "Marek Olšák"
To: "Keith Whitwell"
Cc: mesa-dev@lists.freedesktop.org
Sent: Sunday, 6 February, 2011 12:01:01 PM
Subject: Re: [Mesa-dev] Gallium proposal: add a user pointer in pipe_resource
Hi Keith,
1) Recreating user buffe
On Tue, 2011-02-08 at 22:29 +0100, Marek Olšák wrote:
>
>
> Keith,
>
> redefine_user_buffer() would be a good compromise and I believe the
> performance hit wouldn't be so noticable. It would also allow partial
> uploads of constants in a user buffer, which is something we'd like to
> have
> too
On Tue, 2011-02-08 at 22:51 +0100, Marek Olšák wrote:
>
> void redefine_user_buffer(
> struct pipe_context*,
> struct pipe_resource*,
> unsigned offset,
> unsigned size);
>
> and new width0 would implicitly be offset+size;
>
I think this is a great place to start
Marek,
These patches look good, but have you covered the case where the application is
changing the contents of vertex arrays without rebinding/notifying GL in any
way?
eg. an app could do:
memcpy(varray, foo, ...);
glDrawArrays(...);
memcpy(varray, bar, ...);
glDrawArrays(...);
wi
On Sun, 2011-02-13 at 22:04 +0100, Marek Olšák wrote:
> Keith,
>
> Yes, they will. If vertex buffers are not re-set in st_draw_vbo,
> redefine_user_buffer is called for each user buffer which is set and that
> tells a driver which buffer ranges need to be re-uploaded. This can be found
> in the la
I certainly have no objection for i965... Dave and Jakob probably need
to comment also.
Keith
On Wed, 2011-02-16 at 13:35 -0500, Kristian Høgsberg wrote:
> They're not maintained and gets in the way when loading EGL drivers.
> The doc string even says it's disabled by default.
> ---
>
> I think
I've always wondered why freeGLUT gives such poor numbers for gears and
similar high-framerate demos relative to the original.
It looks like one reason is the code added for Spaceball handling which
tries to initialize the Spaceball device every frame, even if it
previously failed. The trouble be
Looks good Marek.
Keith
On Sun, 2011-02-20 at 16:52 +0100, Marek Olšák wrote:
> This fixes the game Tiny and Big.
> ---
> src/mesa/state_tracker/st_cb_clear.c | 16 ++--
> 1 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_clear.c
> b/
Looks good to me.
Keith
On Sun, 2011-02-20 at 18:14 +0100, Marek Olšák wrote:
> If two buffers had the same stride where one buffer is a user one and
> the other is a vbo, it was considered to be one interleaved buffer,
> resulting in incorrect rendering and crashes.
>
> This patch makes sure th
Looks good Marek.
Keith
On Wed, 2011-02-23 at 07:44 +0100, Marek Olšák wrote:
> From: Wiktor Janas
>
> Ptr can be very well NULL, so when there are two arrays, with one having
> offset 0 (and thus NULL Ptr), and the other having a non-zero offset,
> the non-zero value is taken as minimum (becau
On Tue, 2011-03-01 at 13:18 +0100, Blaž Tomažič wrote:
> On Mon, 2011-02-28 at 16:39 -0800, Brian Paul wrote:
> > On Mon, Feb 28, 2011 at 4:13 PM, Blaž Tomažič
> > wrote:
> > > Hi Mesa developers,
> > >
> > > I am really interested in Gallium3D and I'm thinking about a project for
> > > my diplo
On Tue, 2011-03-01 at 12:32 -0800, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/01/2011 05:36 AM, Keith Whitwell wrote:
>
> > Create an automated bug-finder for gallium drivers.
> >
> > Step one: create a "split and com
On Fri, 2011-03-04 at 07:02 -0800, Jose Fonseca wrote:
> Module: Mesa
> Branch: master
> Commit: 6838c9ce74f16c765474c0d2b4ae1469dd4a64d5
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=6838c9ce74f16c765474c0d2b4ae1469dd4a64d5
>
> Author: José Fonseca
> Date: Fri Mar 4 14:54:24 2
On Sun, 2011-03-06 at 18:42 +0100, Marek Olšák wrote:
>
> Hi,
>
> I have several questions about Gallium. Some of them are about
> undocumented
> stuff, others are just little things from the top of my head. Please
> consider these as things I may do when time allows.
>
>
> 1) Flush flags
>
>
On Mon, 2011-03-07 at 20:47 +1000, Dave Airlie wrote:
> On Mon, Mar 7, 2011 at 3:42 AM, Marek Olšák wrote:
> > Hi,
> >
> > I have several questions about Gallium. Some of them are about undocumented
> > stuff, others are just little things from the top of my head. Please
> > consider these as thin
Isn't this PIPE_USAGE_STREAM ?
Keith
On Sat, 2011-03-05 at 17:54 +0100, Jakob Bornecrantz wrote:
> Hi all
>
> Short and simple patch series attached.
>
> Some drivers can treat one shot resources differently then resources
> that are expected to be used several times. Add a usage flag to allow
On Mon, 2011-03-07 at 18:52 +0100, Marek Olšák wrote:
> > 6) Pixel buffer objects
> > >
> > > It woud be nice to have hardware-accelerated PBO copy in Gallium.
> > > Would
> > > resource_copy_region be a good candidate for this, where one of
> the
> > > arguments would be PIPE_BUFFER and the other
On Thu, 2011-03-10 at 20:25 +0100, Marek Olšák wrote:
> Hi,
>
> I have reviewed where we call flush() and why and some of them
> seem unnecessary to me. Those flushes may slightly decrease
> performance, depending on each driver, and may hide driver bugs.
>
> glFlush doesn't have to be called in
On Fri, 2011-03-11 at 06:05 +0100, Marek Olšák wrote:
> Hi,
>
> these 2 patches add GL_NV_texture_barrier to Mesa and Gallium,
> respectively. The extension can be used for programmable
> blending, where the same texture can be bound as both a sampler
> and renderbuffer. The same feature exists in
>
> I have done some of the changes in the gallium interface we discussed
> in the
> thread called "7 questions...".
>
> There are 4 patches in total:
>
> 1) gallium: kill is_resource_referenced
>
> The function is_resource_referenced is removed. Considering that only
> st/xorg used it, I don'
On Sat, 2011-03-12 at 00:48 +0100, Marek Olšák wrote:
> On Fri, Mar 11, 2011 at 2:56 PM, Keith Whitwell wrote:
> >
> > So my suggestion would be to name this something else, perhaps taking
> > language from the NV extension.
> >
>
> Alright.
>
> There
On Mon, 2011-03-21 at 02:12 +0100, Marek Olšák wrote:
> diff --git a/src/gallium/include/pipe/p_state.h
> b/src/gallium/include/pipe/p_state.h
> index cf6c5b5..f6ad456 100644
> --- a/src/gallium/include/pipe/p_state.h
> +++ b/src/gallium/include/pipe/p_state.h
> @@ -81,6 +81,8 @@ struct pipe_raster
On Mon, 2011-03-21 at 16:23 +0100, Christoph Bumiller wrote:
> On 03/21/2011 02:12 AM, Marek Olšák wrote:
>
> > diff --git a/src/gallium/include/pipe/p_state.h
> > b/src/gallium/include/pipe/p_state.h
> > index cf6c5b5..f6ad456 100644
> > --- a/src/gallium/include/pipe/p_state.h
> > +++ b/src/gal
On Mon, 2011-03-21 at 19:28 +0100, Tilman Sauerbeck wrote:
> Signed-off-by: Tilman Sauerbeck
> ---
>
> update_samplers() showed up in a profile of Heroes of Newerth;
> this patch pushes it down the profile by ~3%.
>
> Does this seem plausible?
>
> src/mesa/state_tracker/st_atom_sampler.c |
On Mon, 2011-03-21 at 19:55 +0100, Tilman Sauerbeck wrote:
> Keith Whitwell [2011-03-21 18:43]:
> > On Mon, 2011-03-21 at 19:28 +0100, Tilman Sauerbeck wrote:
> > > Signed-off-by: Tilman Sauerbeck
> > > ---
> > >
> > > update_samplers() showed up
On Mon, 2011-03-28 at 17:54 -0400, Jerome Glisse wrote:
> Hi,
>
> One short coming of macro has keep entertaining me until i figure out
> what was wrong, here is
> a simple scenario :
>
> Macro can lead to hard to debug list bugs. For instance consider
> the following :
> LIST_ADD(item, list->pre
On Mon, 2011-03-28 at 17:54 -0400, Jerome Glisse wrote:
> Hi,
>
> One short coming of macro has keep entertaining me until i figure out
> what was wrong, here is
> a simple scenario :
>
> Macro can lead to hard to debug list bugs. For instance consider
> the following :
> LIST_ADD(item, list->pre
On Wed, 2011-03-30 at 14:33 +0200, Marek Olšák wrote:
> From: Luca Barbieri
>
> Disclaimer:
> I will not push this code if this patch does not get any attention,
> because I cannot say if it is 100% correct (the code is not mine).
> However last time I checked, it passed all the related tes
> On Wed, Mar 30, 2011 at 2:45 PM, Keith Whitwell
> wrote:
>
> > > diff --git a/src/gallium/auxiliary/draw/draw_llvm.h
> > b/src/gallium/auxiliary/draw/draw_llvm.h
> > > index e8623e7..643a9ef 100644
> > > --- a/src/gallium/auxiliary/draw/draw_llv
Looks good to me, Jose.
Keith
On Thu, 2011-03-31 at 14:45 +0100, jfons...@vmware.com wrote:
> From: José Fonseca
>
> Based on some code and ideas from Keith Whitwell.
> ---
> src/gallium/auxiliary/Makefile |1 +
> src/gallium/au
Looks good.
Keith
On Thu, 2011-03-31 at 14:46 +0100, jfons...@vmware.com wrote:
> From: José Fonseca
>
> Not added to the standard test lists given that ARB_vertex_buffer_object
> allows program termination out-of-bounds vertex buffer object fetches
> occur.
> ---
> tests/general/CMakeLists.gl
On Mon, 2011-04-11 at 10:30 -0700, Ian Romanick wrote:
> The first patch "fixes" an issue that Ken and I discovered last week
> with the ROUND_DOWN_TO macro in the i965 driver. The best fix is
> probably to pull this macro up into higher-level Mesa code. I'd like
> some review that changing this
I'd like to get rid of the zero stride concept and require the state
tracker to either turn those values into proper constant (easy now we
can bind >1 constant buffer) or use instancing to get the same effect.
Keith
On 11 Apr 2010, at 00:27, Zack Rusin wrote:
On Saturday 10 April 2010 18
On Sun, Apr 11, 2010 at 9:33 AM, Luca Barbieri wrote:
> Why?
>
> At least all nVidia cards directly support this, and it allows code like this:
>
> hw_set_vertex_attrib(idx, v)
> {
> write command to set vertex attrib on GPU fifo
> write idx on GPU fifo
> write v on GPU fifo
> return;
On Sun, Apr 11, 2010 at 6:38 PM, Keith Whitwell
wrote:
> On Sun, Apr 11, 2010 at 9:33 AM, Luca Barbieri wrote:
>> Why?
>>
>> At least all nVidia cards directly support this, and it allows code like
>> this:
>>
>> hw_set_vertex_attrib(idx, v)
>> {
&g
This makes sense & looks good to me Dave.
Keith
On Mon, Apr 12, 2010 at 6:46 AM, Dave Airlie wrote:
> So I've been trying to make r300g do point sprites for a few days now,
> and I've pulled out quite a lot of hair blaming pieces of hardware
> along with random r300g states.
>
> I finally notice
On Mon, Apr 12, 2010 at 9:55 AM, Christoph Bumiller
wrote:
> On 04/12/2010 10:22 AM, Luca Barbieri wrote:
>
4. More powerful and better defined clear interface with scissor/MRT
support
>>>
>>> I'm not sure how scissors fit in, other than that you probably have to
>>> hax them on your HW
On Mon, 2010-04-12 at 07:56 -0700, Alex Deucher wrote:
> On Mon, Apr 12, 2010 at 10:17 AM, Roland Scheidegger
> wrote:
> > What's wrong with the stride zero concept?
> > I think most hw can handle this just fine (pretty sure all radeons
> > should, though of course driver might need some special
2010/4/13 Dave Airlie :
> No offence to gallium, but I don't think its been mature enough to
> ship a driver for as long as Intel have had to ship drivers. I'm not
> even sure its mature enough to ship a driver with yet. I know you guys
> have shipped drivers using it, but I don't count the closed
Looks good to me.
Keith
On Tue, Apr 13, 2010 at 11:22 AM, Chia-I Wu wrote:
> From: Chia-I Wu
>
> It has no user after the removal of st_public. Plus, it has never been
> implemented by a pipe driver or winsys.
> ---
> src/gallium/auxiliary/util/u_simple_screen.h | 5 -
> src/gallium/in
I'm much more relaxed about the future of Gallium these days. I don't
think there's any sense in pushing people or projects towards it -
people are welcome to evaluate it on its merits and make their own
decisions on that basis.
The project itself is clearly on a strong footing. We've shown we c
On Tue, Apr 13, 2010 at 11:47 PM, Keith Whitwell
wrote:
> I'm much more relaxed about the future of Gallium these days. I don't
> think there's any sense in pushing people or projects towards it -
> people are welcome to evaluate it on its merits and make their own
&
On Tue, 2010-04-13 at 23:27 -0700, Dave Airlie wrote:
> So I've finished the r300g point sprite code and this test fails,
> fglrx fails the exact same way.
>
> http://people.freedesktop.org/~airlied/piglit/fglrx/fglrxr500/test_glean__pointSprite.html
>
> It appears the point size where the textur
On Mon, 2010-04-19 at 06:07 -0700, Marek Olšák wrote:
> Unfortunately, this is supported only on r500 (i.e. not r300 nor r400)
> and only when the DRM version is >=2.3.0 (i.e. kernel 2.6.34). Please,
> can we make it an optional feature?
Are you sure about this? It seems to be a long-time DX9 (an
On Mon, 2010-04-19 at 09:49 -0700, José Fonseca wrote:
> On Mon, 2010-04-19 at 06:22 -0700, Keith Whitwell wrote:
> > On Mon, 2010-04-19 at 06:07 -0700, Marek Olšák wrote:
> > > Unfortunately, this is supported only on r500 (i.e. not r300 nor r400)
> > > and only when
On Fri, 2010-04-23 at 04:12 -0700, Jakob Bornecrantz wrote:
> Hi all
>
> So mesa has a fair bit of branches just laying around not doing
> anything. I wrote a quick script that prints the branch name and the
> number of commits that this branch has which are not on the master
> branch. I have a
On Sat, 2010-04-24 at 07:25 -0700, Jakob Bornecrantz wrote:
> Hi Chia-I et all
>
> This Patch series does some minor refactoring in the st_api interface
> and some major one to st/dri.
>
> The first patch drops the st_module struct from st_api. This is because it
> was overlapping the st_api stru
On Mon, 2010-04-26 at 11:54 +0100, Keith Whitwell wrote:
> On Sat, 2010-04-24 at 07:25 -0700, Jakob Bornecrantz wrote:
> > Hi Chia-I et all
> >
> > This Patch series does some minor refactoring in the st_api interface
> > and some major one to st/dri.
> >
> &
On Mon, 2010-04-26 at 07:43 -0700, ja...@vmware.com wrote:
> From: Jakob Bornecrantz
>
> In short what the code did before:
>
> __DRIscreen *psp = NULL;
> if (pcp)
>psp = pcp->psb;
>
> assert(psp);
> if (psp->stuff)
>other_stuff();
>
> return psb->even_more(
On Mon, 2010-04-26 at 11:27 -0700, José Fonseca wrote:
> Hi Roland,
>
> Overall looks good. It's nice to finally have a way to export MSAA
> capabilities, and see the pipe_surfaces use being more constrained.
>
> A few comments inline, but no strong feelings so feel free to do as you
> wish.
> >
What the f ? :)
Keith
--- Begin Message ---
Module: Mesa
Branch: 7.8
Commit: 39bd4602c0c31d4984293fd6e419405aca32d940
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=39bd4602c0c31d4984293fd6e419405aca32d940
Author: Jeremy Huddleston
Date: Tue Apr 27 12:22:50 2010 -0700
f
Signed-of
On Wed, 2010-04-28 at 02:26 -0700, Dave Airlie wrote:
> On Wed, Apr 28, 2010 at 7:13 PM, Jose Fonseca wrote:
> > No need to go into this blame game, especially not for this feature. Which
> > is pretty easy to implement on svga pipe driver -- we already generate
> > shader variants, so it is jus
Jakob,
A couple of these are a bit misleading - DX10 & DX11 aren't fully
supportable without further changes & extensions to gallium, so it seems
misleading to have these ever return true - at least until those changes
are done.
Would it make sense to have a UTIL_CHECK_NONIMPLEMENTED or similar t
> I happen to do mesa development work on about 10 different machines,
> so yes I generally keep one mesa tree on each as close to master as I
> can get. Again you are developing for swrast or for vmware. Try
> developing for something like radeon and intel on different days, I
> have to keep a num
On Fri, 2010-04-30 at 09:42 -0700, Corbin Simpson wrote:
> On Fri, Apr 30, 2010 at 6:54 AM, Keith Whitwell
> wrote:
> >> I happen to do mesa development work on about 10 different machines,
> >> so yes I generally keep one mesa tree on each as close to master as I
>
On Sun, 2010-05-02 at 11:04 -0700, José Fonseca wrote:
> On Sun, 2010-05-02 at 09:34 -0700, Corbin Simpson wrote:
> > So I got bored a few days ago and broke ground on a little bit of code
> > I've had in mind for a while. This is a new state tracker, Pylladium,
> > that acts to expose the core Gal
On Tue, 2010-05-04 at 22:48 -0700, Chia-I Wu wrote:
> 2010/5/2 Chia-I Wu :
> > I've been working on and off for a while on a dispatcher builder called mapi
> > (multiple-api, in contrary to gl-api). The code is available at
> >
> > http://cgit.freedesktop.org/~olv/mesa/log/?h=mapi
> >
> > The mot
On Tue, 2010-05-04 at 14:01 -0700, Gregory Prisament wrote:
> Hi,
> I just did a "git pull" and I'm no longer able to build the egl demo
> apps (mesa/progs/egl/opengles1/* and mesa/progs/egl/opengles2/*).
> These were working for me previously.
>
> ES1:
> gcc -g -O2 -Wall -Wmissing-prototypes -std
Brian,
My understanding is that gallium has chosen to simplfy itself slightly
and treat quad rasterization as always following GL flatshading
conventions. Does/could your change follow that convention?
Keith
On Wed, 2010-05-05 at 11:34 -0700, Brian Paul wrote:
> Commit ddb0e18f6c5582d4d2cc59ffd
On Wed, 2010-05-05 at 20:12 +0100, Keith Whitwell wrote:
> Brian,
>
> My understanding is that gallium has chosen to simplfy itself slightly
> and treat quad rasterization as always following GL flatshading
> conventions. Does/could your change follow that convention?
Ugh,
On Thu, 2010-05-06 at 01:14 -0700, Liu wrote:
> hi all
> I saw http://llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf , it
> is COOL! So I want to do somthing like this on Mesa. Now, I want a
> glsl parser, as, linker, and some doc. of them. So I can write CG for
> llvm, and then write the back
On Fri, 2010-05-07 at 10:47 -0700, Jakob Bornecrantz wrote:
> 2010/5/7 Kristian Høgsberg :
> > 2010/5/7 Jakob Bornecrantz :
> > ...
> >>> No I understand that. We currently have an interface between libEGL
> >>> and the EGL driver it loads. You're proposing to move that interface
> >>> up the sta
On Tue, 2010-05-11 at 15:01 -0700, José Fonseca wrote:
> On Tue, 2010-05-11 at 07:45 -0700, Marek Olšák wrote:
> > On Tue, May 11, 2010 at 12:49 PM, José Fonseca
> > wrote:
> > Attached is my proposal for fine grained caps for shader
> > limits.
> >
> > I'd like have a cap for Max
I'm considering modifying the gallium rasterizer state to remove most of
the cw/ccw flags and replace them with front/back or other concepts
closer to what GL is using.
This is primarily motivated by the fact that noone other than GL uses a
lot of this state, and where they do, they tend to use th
Looks good to me...
Keith
On Fri, 2010-05-14 at 10:04 -0700, Marek Olšák wrote:
> ---
> src/gallium/drivers/svga/svga_swtnl.h|1 -
> src/gallium/drivers/trace/tr_dump.h |1 -
> src/gallium/include/pipe/p_screen.h |1 -
> src/gallium/include/state_tracker/dri
On Sun, 2010-05-16 at 12:34 -0700, Mathias Fröhlich wrote:
> Hi,
>
> The attached patch adds EXT_timer_query support to the mesa state tracker.
> It does so by adding a new pipe capability for the timer queries and a new
> type for the query objects.
> Also a softpipe driver implementation for th
On Tue, 2010-05-18 at 04:37 -0700, Michal Krol wrote:
> From eaba49550f92af708499f22dbaa7cf4d99f4109f Mon Sep 17 00:00:00 2001
> From: Michal Krol
> Date: Tue, 18 May 2010 12:39:01 +0200
> Subject: [PATCH] softpipe: Calculate slice_stride field in get_transfer().
>
> ---
> src/gallium/drivers/so
So, the front vs. ccw feature branch is working pretty well for softpipe
and llvmpipe.
I've got some documentation fixup to do, but it would also be good if
the various driver owners could take a look at the changes there. I've
tried to adjust each driver correctly, but it's likely that mistake
On Wed, 2010-05-19 at 05:29 -0700, Keith Whitwell wrote:
> So, the front vs. ccw feature branch is working pretty well for softpipe
> and llvmpipe.
>
> I've got some documentation fixup to do, but it would also be good if
> the various driver owners could take a look at the
>
> Anyway, the new clearRT/clearDS functions aren't implemented by all
> drivers yet. That should be ok for now since they didn't use to
> implement surface_fill neither.
> Also, the interface of these is not set in stone yet. In particular,
> they can handle a region, which is needed by d3d9, b
101 - 200 of 248 matches
Mail list logo
