On 06.09.2010 22:03, Luca Barbieri wrote:
>>> This way you could copy z24s8 to r8g8b8a8, for instance.
>
>> I am not sure this makes a lot of sense. There's no guarantee the bit
>> layout of these is even remotely similar (and it likely won't be on any
>> decent hardware). I think the dx10 restric
On 06.09.2010 17:16, Luca Barbieri wrote:
> On Mon, Sep 6, 2010 at 3:57 PM, José Fonseca wrote:
>> I'd like to know if there's any objection to change the
>> resource_copy_region semantics to allow copies between different yet
>> compatible formats, where the definition of compatible formats is:
>
On 06.09.2010 15:57, José Fonseca wrote:
> I'd like to know if there's any objection to change the
> resource_copy_region semantics to allow copies between different yet
> compatible formats, where the definition of compatible formats is:
>
> "formats for which copying the bytes from the source
On 26.04.2010 20:26, 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.
>> diff --git a/sr
On 14.04.2010 00:38, Dave Airlie wrote:
> On Wed, Apr 14, 2010 at 8:33 AM, Roland Scheidegger
> wrote:
>> On 13.04.2010 20:28, Alex Deucher wrote:
>>> On Tue, Apr 13, 2010 at 2:21 PM, Corbin Simpson
>>> wrote:
>>>> On Tue, Apr 13, 2010 at 6:42 AM,
On 13.04.2010 20:28, Alex Deucher wrote:
> On Tue, Apr 13, 2010 at 2:21 PM, Corbin Simpson
> wrote:
>> On Tue, Apr 13, 2010 at 6:42 AM, Roland Scheidegger
>> wrote:
>>> On 13.04.2010 02:52, Dave Airlie wrote:
>>>> On Tue, Apr 6, 2010 at 2:00 AM, Bri
On 13.04.2010 02:52, Dave Airlie wrote:
> On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul wrote:
>> Dave Airlie wrote:
>>> Just going down the r300g piglit failures and noticed fbo-drawbuffers
>>> failed, I've no idea
>>> if this passes on Intel hw, but it appears the texenvprogram really
>>> needs to
On 10.04.2010 17:10, Keith Whitwell wrote:
> On Sat, Apr 10, 2010 at 4:05 PM, Keith Whitwell
> wrote:
>> On Sat, Apr 10, 2010 at 3:49 PM, Roland Scheidegger
>> wrote:
>>> On 10.04.2010 16:43, Chia-I Wu wrote:
>>>> On Sat, Apr 10, 2010 at 8:00 PM, Keith Wh
On 10.04.2010 16:43, Chia-I Wu wrote:
> On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell
> wrote:
>> Hmm, not sure whether to merge or squash-merge this branch. Any thoughts?
> The conversion to pipe_resource seems to be done by components. Maybe a new
> branch that reorganize (git rebase -i) the
On 10.04.2010 14:00, Keith Whitwell wrote:
> Hmm, not sure whether to merge or squash-merge this branch. Any thoughts?
I'm no big fan of squash merge but the history of the normal merge won't
be nice neither. Tough call, though I'd prefer a normal merge.
Roland
-
On 09.04.2010 18:22, José Fonseca wrote:
> On Fri, 2010-04-09 at 09:02 -0700, Keith Whitwell wrote:
>> On Fri, 2010-04-09 at 08:59 -0700, Roland Scheidegger wrote:
>>> On 09.04.2010 17:49, Keith Whitwell wrote:
>>>> On Fri, 2010-04-09 at 08:45 -0700, Roland Scheide
On 09.04.2010 17:29, STEVE555 wrote:
> Hi all,
> I've git branched and got the latest commits from the
> gallium-resources branch and also the latest commits from git master.
>
> I did a gmake -B realclean from a prevous compile on my copy of git
> master,and did a git checkout gallium-re
On 09.04.2010 17:49, Keith Whitwell wrote:
> On Fri, 2010-04-09 at 08:45 -0700, Roland Scheidegger wrote:
>> Module: Mesa
>> Branch: gallium-resources
>> Commit: faf53328d1154c51d8a59513f2bfcae62272b0bf
>> URL:
>> http://cgit.fre
On 02.04.2010 17:09, Luca Barbieri wrote:
> Additionally, the S3TC library may now support only a subset of the
> formats. This may be even more useful as further compressed formats
> are added.
FWIW, I don't see any new s3tc formats. rgtc will not be handled by s3tc
library since it isn't paten
On 02.04.2010 17:18, Luca Barbieri wrote:
> How about merging gallium-buffer-usage-cleanup as well, which is based
> on gallium-resources?
> Unless, it changed recently, the gallium-resources branch left a mix
> of old PIPE_BUFFER_USAGE_* and new PIPE_TRANSFER_* flags.
>
> It would nice to convert
I'm planning on merging the gallium-resources branch shortly (after
easter). Due to the amount of code changed, it wouldn't be unexpected if
some drivers break here and there. So it would be nice if the respective
driver authors could take a look at that branch now.
If you've missed the discussion
On 29.03.2010 04:50, Marek Olšák wrote:
> We were talking a bit on IRC that the GLSL compiler implements the sqrt
> function somewhat inefficiently. Instead of rsq+rcp+cmp instructions as
> is in the original code, the proposed patch uses just rsq+mul. Please
> see the patch log for further explan
On 22.03.2010 17:46, Luca Barbieri wrote:
> The code was half converted, resulting in texturing being totally
> broken.
>
> [sending this because my account hasn't been created yet]
>
> ---
> src/gallium/drivers/nvfx/nv30_fragtex.c |2 +-
> src/gallium/drivers/nvfx/nv40_fragtex.c |2 +-
>
On 16.03.2010 18:52, Keith Whitwell wrote:
> On Tue, 2010-03-16 at 08:32 -0700, Ian Romanick wrote:
>
>> I'm also a bit surprised that not detecting GL_EXT_compiled_vertex_array
>> has any impact on our Quake3 performance. After all, our CVA
>> implementation doesn't do anything! Looking at the
On 13.03.2010 03:20, Corbin Simpson wrote:
> On Fri, Mar 12, 2010 at 5:20 PM, Jose Fonseca
> wrote:
>> Because if you have a huge vertex buffer and you only draw few
>> indices you may choose to upload to VRAM only the vertices actually
>> referred. Applications do this. And for certain hardware u
On 11.03.2010 17:54, Brian Paul wrote:
> Roland Scheidegger wrote:
>> Hi,
>>
>> there are currently a couple of extensions enabled in the mesa state
>> tracker which probably shouldn't be. These were moved there by commit
>> a0ae2ca033ec2024da1e01d1c11c04
Hi,
there are currently a couple of extensions enabled in the mesa state
tracker which probably shouldn't be. These were moved there by commit
a0ae2ca033ec2024da1e01d1c11c0437837c031b (that is with dri they were
already always enabled before).
Someone knows off-hand which one we can enable or not
to be independent of windowing systems. That said from what I
> can see both driInitExtensions and driInitSignleExtension could be
> folded into mesa core, I can't see anything "dri special" about them.
>
> Cheers Jakob.
>
> On 8 mar 2010, at 16.12, Roland Scheidegge
ed or is it OK?
>
> -Marek
>
> On Mon, Mar 8, 2010 at 4:25 PM, Roland Scheidegger <mailto:srol...@vmware.com>> wrote:
>
> On 08.03.2010 14:22, Joakim Sindholt wrote:
> > On Mon, 2010-03-08 at 13:16 +0100, Roland Scheidegger wrote:
> >> On
On 08.03.2010 14:22, Joakim Sindholt wrote:
> On Mon, 2010-03-08 at 13:16 +0100, Roland Scheidegger wrote:
>> On 07.03.2010 20:26, Marek Olšák wrote:
>>> This branch is aimed to address the following issues:
>>> * Extensions are advertised in both st/mesa and st/dri,
On 07.03.2010 20:26, Marek Olšák wrote:
> This branch is aimed to address the following issues:
> * Extensions are advertised in both st/mesa and st/dri, doing the same
> thing in two places.
> * The inability to disable extensions in pipe_screen::get_param because
> st/dri overrides the decisions
On 07.03.2010 01:21, José Fonseca wrote:
> On Sat, 2010-03-06 at 05:44 -0800, Brian Paul wrote:
>> On Sat, Mar 6, 2010 at 5:44 AM, José Fonseca wrote:
>>> On Mon, 2010-03-01 at 09:03 -0800, Michel Dänzer wrote:
On Fri, 2010-02-26 at 08:47 -0800, Jose Fonseca wrote:
> Module: Mesa
> Br
On 03.03.2010 20:23, Luca Barbieri wrote:
>> And never will... It does not export PIPE_CAP_GLSL, and does not have
>> the shader opcodes to ever do so.
>
> Any Gallium driver should be able to support the GLSL subset without
> control flow.
>
> And if we had a proper optimization infrastructure
On 03.03.2010 14:07, José Fonseca wrote:
> On Wed, 2010-03-03 at 04:27 -0800, Luca Barbieri wrote:
>>> PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa.
>>> PIPE_FORMAT_R8G8B8X8_UNORM doesn't exist hence it appears to be
>>> unnecessary. So it doesn't make sense to rename.
>> How about D3DFMT_X8B8G
On 02.03.2010 11:37, Keith Whitwell wrote:
> On Mon, 2010-03-01 at 10:02 -0800, Roland Scheidegger wrote:
>> Hi,
>>
>> this branch turns vertex element into a cso, so instead of
>> set_vertex_elements there's now the triad of
>> create/bind/delete_vertex_el
On 02.03.2010 00:18, Joakim Sindholt wrote:
> On Mon, 2010-03-01 at 19:02 +0100, Roland Scheidegger wrote:
>> Hi,
>>
>> this branch turns vertex element into a cso, so instead of
>> set_vertex_elements there's now the triad of
>> create/bind/delete_vertex_el
On 01.03.2010 19:02, Roland Scheidegger wrote:
> Hi,
>
> this branch turns vertex element into a cso, so instead of
> set_vertex_elements there's now the triad of
> create/bind/delete_vertex_elements_state. I have converted all the
> drivers except nouveau (I didn&#x
Hi,
this branch turns vertex element into a cso, so instead of
set_vertex_elements there's now the triad of
create/bind/delete_vertex_elements_state. I have converted all the
drivers except nouveau (I didn't do it because Christoph Bumiller
already did nv50, but I can give the rest of them a shot)
On 25.02.2010 18:39, michal wrote:
> Roland Scheidegger wrote on 2010-02-24 15:18:
>> On 24.02.2010 12:48, Christoph Bumiller wrote:
>>
>>> This wasn't a problem before because textures and samplers were
>>> linked 1:1, but in view of the gallium-gpu4-textu
On 24.02.2010 12:48, Christoph Bumiller wrote:
> This wasn't a problem before because textures and samplers were
> linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch,
> this coordinate normalization bit becomes a problem.
>
> NV50 hardware has that bit in the RESOURCE binding, and
Marek,
I don't particularly like that patch, because it doesn't really fix the
problem with the extension handling.
There are lots of extension listed there which should not be advertized
by default, so picking one out won't fix the others.
I think they are there because driInitExtensions definite
This isn't actually true any more. See issue (9) of
ARB_framebuffer_object which defines luminance, luminance_alpha and
intensity as renderable.
(I'm not quite sure how color assignment is done, readpixels and the
like would define L = R + G + B, but I think it will follow the table
from texture im
On 12.02.2010 20:20, Corbin Simpson wrote:
> On Fri, Feb 12, 2010 at 10:49 AM, Brian Paul wrote:
>> Roland Scheidegger wrote:
>>> On 12.02.2010 19:00, Keith Whitwell wrote:
>>>> On Fri, 2010-02-12 at 09:56 -0800, Roland Scheidegger wrote:
>>>>> On 12.0
On 12.02.2010 19:00, Keith Whitwell wrote:
> On Fri, 2010-02-12 at 09:56 -0800, Roland Scheidegger wrote:
>> On 12.02.2010 18:42, Keith Whitwell wrote:
>>> On Fri, 2010-02-12 at 09:28 -0800, José Fonseca wrote:
>>>> On Fri, 2010-02-12 at 06:43 -0800, Roland Scheideg
On 12.02.2010 18:42, Keith Whitwell wrote:
> On Fri, 2010-02-12 at 09:28 -0800, José Fonseca wrote:
>> On Fri, 2010-02-12 at 06:43 -0800, Roland Scheidegger wrote:
>>> On 12.02.2010 14:44, michal wrote:
>>>> Keith Whitwell wrote on 2010-02-12 14:28:
>>>>&
On 12.02.2010 18:28, José Fonseca wrote:
> On Fri, 2010-02-12 at 06:43 -0800, Roland Scheidegger wrote:
>> On 12.02.2010 14:44, michal wrote:
>>> Keith Whitwell wrote on 2010-02-12 14:28:
>>>> On Fri, 2010-02-12 at 05:09 -0800, michal wrote:
>>>>
>
Hello,
I'd like to merge the gallium-dynamicstencilref branch soon.
This moves the stencil reference value(s) out of the cso, because this
is a bit more dynamic state (i.e. changes more often) (there are
algorithms out there which change this quite often).
There's also some minor adjustments to ma
On 12.02.2010 14:44, michal wrote:
> Keith Whitwell wrote on 2010-02-12 14:28:
>> On Fri, 2010-02-12 at 05:09 -0800, michal wrote:
>>
>>> Keith Whitwell wrote on 2010-02-12 13:39:
>>>
On Fri, 2010-02-12 at 04:32 -0800, Micha?? Kr??l wrote:
> Module: Mesa
> B
On 11.02.2010 22:21, Christoph Bumiller wrote:
> On 02/11/2010 10:10 PM, Roland Scheidegger wrote:
>> On 11.02.2010 21:42, Christoph Bumiller wrote:
>>> On 02/11/2010 09:02 PM, Roland Scheidegger wrote:
>>>> Hi,
>>>>
>>>> could one of
On 11.02.2010 21:42, Christoph Bumiller wrote:
> On 02/11/2010 09:02 PM, Roland Scheidegger wrote:
>> Hi,
>>
>> could one of the nouveau developers please take a look at the nv30
>> changes I did for the stencil ref changes in gallium-dynamicstencilref
>> branch?
Hi,
could one of the nouveau developers please take a look at the nv30
changes I did for the stencil ref changes in gallium-dynamicstencilref
branch?
I've just done that in a way I think it might make sense, but I've
absolutely no idea if it would work like that (and even if it would in
theory the
On 08.02.2010 18:27, Brian Paul wrote:
> On Mon, Feb 8, 2010 at 10:21 AM, Roland Scheidegger
> wrote:
>> This branch removes point_size_min and point_size_max because most
>> hardware doesn't have any register to clamp this at rasterization time
>> (from all galliu
This branch removes point_size_min and point_size_max because most
hardware doesn't have any register to clamp this at rasterization time
(from all gallium drivers, only r300 had this), and the mesa state
tracker actually never used these field properly. The clamp to
implementation limits will now
On 06.02.2010 15:07, Marc Dietrich wrote:
> also update the cell config a bit
> ---
> configs/linux-cell |6 ++--
> src/gallium/drivers/cell/common.h |3 +-
> src/gallium/drivers/cell/spu/spu_per_fragment_op.c | 36
> ++--
On 05.02.2010 22:48, Corbin Simpson wrote:
> Two things...
>
> Are accumbufs still slow in Gallium-land? Should we still mark them as slow?
>
> How many multisamples should we actually pretend/advertise? Should we
> have a cap to check the number of multisamples supported? Should we
> just say th
On 03.02.2010 17:45, michal wrote:
> Roland Scheidegger wrote on 2010-02-03 16:47:
>> On 03.02.2010 16:07, michal wrote:
>>
>>> Keith,
>>>
>>> This feature branch adds cylindrical wrap texcoord mode to gallium
>>> shader tokens and removes p
On 03.02.2010 16:07, michal wrote:
> Keith,
>
> This feature branch adds cylindrical wrap texcoord mode to gallium
> shader tokens and removes prefilter field from sampler state.
> Implemented cylindrical wrapping for linear interpolator in softpipe.
> Not sure whether it makes sense to do it f
On 01.02.2010 20:23, Brian Paul wrote:
> Speaking of texture formats and texture sampling, one area of Gallium
> that's under-specified is what (x,y,z,w) values are returned by TEX
> instructions when sampling from each of the various texture formats.
>
> A while back I started a table comparing
On 31.01.2010 18:41, Christoph Bumiller wrote:
> On 31.01.2010 01:37, Roland Scheidegger wrote:
>> Marek Olšák wrote:
>>
>>> 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in
>>> the fragment constants read
Corbin Simpson wrote:
>
>>> Another
>>> comment reads, "Gallium doesn't provide us with any information
>>> regarding this mode, so we are screwed. I'm setting 0 = LUMINANCE,"
>>> above the texture compare modes. I don't really like that section of
>>> code, but it probably can't get cleaner, righ
Marek Olšák wrote:
> 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in
> the fragment constants reads, "Since Gallium doesn't support
> GL_ARB_shadow_ambient, this is always (0,0,0,0), right?"
>
> I think the extension could be added to Gallium since the r300 compi
On 30.01.2010 13:06, Corbin Simpson wrote:
> Handful of random things bugging me.
> 2) progs/tests/drawbuffers and progs/tests/drawbuffers2, and possibly
> others, segfault with both softpipe and the HW driver at
> sl_pp_version.c:45. I think there's some codegen going on there? At
> any rate, if
h the branch, and
> the r300g patch looks perfect. I've pushed another patch on top for
> the pipe caps, to avoid post-merge cleanups for myself.
>
> On Tue, Jan 26, 2010 at 7:00 AM, Alex Deucher wrote:
>> On Tue, Jan 26, 2010 at 9:44 AM, Roland Scheidegger
>> wrote:
Hi,
I'm planning on merging this branch to master soon.
This will make it possible to do per render target blend enables,
colormasks, and also per rendertarget blend funcs (with a different CAP
bit for the latter, and this one isn't actually used in mesa state
tracker yet).
None of the drivers oth
On 26.01.2010 09:18, Marvin wrote:
> Jose, Brian,
>
>> Marc,
>>
>> Why is this necessary? It has been working fine so far. Which gcc version
>> are you using? What commas are you referring to?
>
> the PIPE_ALIGN_TYPE macro is so far only used in the cell driver in
> src/gallium/drivers/cell/spu
On 21.01.2010 20:20, michal wrote:
> Hi,
>
> This simple feature branch adds support for two-dimensional constant
> buffers in TGSI.
>
> An example shader would look like this:
>
> FRAG
>
> DCL IN[0], COLOR, LINEAR
> DCL OUT[0], COLOR
> DCL CONST[1][1..2]
>
> MAD OUT[0], IN[0], CONST[1][2], C
On 21.01.2010 18:47, Luca Barbieri wrote:
> On Thu, Jan 21, 2010 at 6:34 PM, Corbin Simpson
> wrote:
>> Maybe it's just me, since I actually wrote the docs, but does anybody
>> else read them?
>>
>> From cso/rasterizer.html (viewable at e.g.
>> http://people.freedesktop.org/~csimpson/gallium-docs/
On 18.01.2010 19:15, Luca Barbieri wrote:
> Breakpoint 3, _mesa_ProgramStringARB (target=34820, format=34933,
> len=70, string=0x85922ba) at shader/arbprogram.c:434
> 434 GET_CURRENT_CONTEXT(ctx);
> $31 = 0x85922ba "!!ARBfp1.0\n\nOPTION
> ARB_precision_hint_fastest;\n\n\n\nEND\
On 11.01.2010 22:03, Zack Rusin wrote:
> 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
On 11.01.2010 18:49, Zack Rusin wrote:
> Hey,
>
> knowing that we're starting to have serious issues with figuring out what
> features the given device supports and what api's/extensions can be
> reasonably
> implemented on top of it I've spent the weekend trying to define feature
> levels. Fe
On 11.01.2010 16:53, Keith Whitwell wrote:
> On Mon, 2010-01-11 at 07:50 -0800, Roland Scheidegger wrote:
>> On 11.01.2010 16:42, Keith Whitwell wrote:
>>> On Mon, 2010-01-11 at 07:33 -0800, Roland Scheidegger wrote:
>>>> Hi,
>>>>
>>>> I&#x
On 11.01.2010 16:42, Keith Whitwell wrote:
> On Mon, 2010-01-11 at 07:33 -0800, Roland Scheidegger wrote:
>> Hi,
>>
>> I'll plan to merge gallium-noconstbuf today. It's a pretty simple API
>> change, so things should continue to run :-).
>
> Roland,
>
Hi,
I'll plan to merge gallium-noconstbuf today. It's a pretty simple API
change, so things should continue to run :-).
Roland
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizo
On 01.01.2010 23:32, Luca Barbieri wrote:
> Currently Gallium defines a specific filtering mode for anisotropic
> filtering.
>
> This however prevents proper implementation of
> GL_EXT_texture_filter_anisotropic.
>
> The spec (written by nVidia) contains the following text: <<< A
> texture's maxi
On 04.01.2010 15:48, Brian Paul wrote:
> Keith Whitwell wrote:
>> On Thu, 2009-12-31 at 15:57 -0800, Brian Paul wrote:
>>> The BY_REGION modes indicate that it's OK for the GPU to discard the
>>> fragments in the region(s) which failed the occlusion test (perhaps
>>> skipping other per-fragment ops
The draw module approach can only work if the texcoords are used
directly for texture lookups, not for calculated coords (it should be
possible to detect these cases though).
Roland
On 21.12.2009 19:32, Keith Whitwell wrote:
> Faking those wrap modes is something that could be done either in the
On 21.12.2009 15:13, Henri Verbeet wrote:
> 2009/12/21 Corbin Simpson :
>> So, yet another thing that r300 sucks balls at: NPOT textures. We've
>> been talking it over on IRC, and here's the options.
>>
>> 1) Don't do NPOT. Stop advertising PIPE_CAP_NPOT, refuse to accept
>> non-NPOT dimensions on
Hello,
I plan to merge gallium-edgeflags branch soon.
I should have fixed up drivers syntactically, but note some will break
if applications use edgeflags. In particular the drivers which so far
have chosen to ignore edgeflags completely and don't have implemented a
fall back to use the draw modul
On 15.12.2009 18:02, michal wrote:
> Roland Scheidegger pisze:
>> On 15.12.2009 14:14, michal wrote:
>>
>>> Guys,
>>>
>>> Does the attached patch make sense to you?
>>>
>>> I replaced the incomplete switch-cases with calls to u_format
On 15.12.2009 14:14, michal wrote:
> Guys,
>
> Does the attached patch make sense to you?
>
> I replaced the incomplete switch-cases with calls to u_format_access
> functions that are complete but are going to be a bit more expensive to
> call. Since they are used not very often in mesa state t
On 14.12.2009 10:29, michael wang wrote:
> Dear Mesa developers,
>
> I am learning OpenGL on my notebook (with an old ATI Radeon X600 video
> card), but I cannot get GL_LINE_STIPPLE work. It draws solid line only.
>
> glxinfo shows I'm using the R300 driver, and some study of the source
> code I
On 09.12.2009 18:58, michal wrote:
> Keith Whitwell pisze:
>> On Wed, 2009-12-09 at 09:16 -0800, michal wrote:
>>
>>> Hi all,
>>>
>>> I would like to merge this branch back to master this week. If anoyone
>>> could test if the build works on his/her system, it would be nice.
>>>
>>> Thanks.
>>>
On 09.12.2009 18:16, michal wrote:
> Hi all,
>
> I would like to merge this branch back to master this week. If anoyone
> could test if the build works on his/her system, it would be nice.
Good stuff!
Looks like only scons build system is working though.
Roland
---
On 08.12.2009 20:57, Martin Olsson wrote:
> Roland Scheidegger wrote:
>> Keith,
>>
>> I think there might be some slight issue with some of the changes in the
>> drivers I did. In particular, I was under the impression it would be ok
>> to do something l
On 08.12.2009 18:12, Roland Scheidegger wrote:
> On 08.12.2009 17:37, Keith Whitwell wrote:
>> On Tue, 2009-12-08 at 08:31 -0800, Roland Scheidegger wrote:
>>> Keith,
>>>
>>> I think there might be some slight issue with some of the changes in the
>>>
On 08.12.2009 17:37, Keith Whitwell wrote:
> On Tue, 2009-12-08 at 08:31 -0800, Roland Scheidegger wrote:
>> Keith,
>>
>> I think there might be some slight issue with some of the changes in the
>> drivers I did. In particular, I was under the impression it would be
asing issues after all these years...
>
> Keith
>
> On Mon, 2009-12-07 at 18:14 -0800, Roland Scheidegger wrote:
>> Hello,
>>
>> I'm planning to merge gallium-strict-aliasing branch soon, which will
>> bring another gallium api change.
>> pipe
On 08.12.2009 16:49, michal wrote:
> Roland Scheidegger pisze:
>> On 08.12.2009 15:55, michal wrote:
>>
>>> This branch simplifies pipe/p_format.h by making enum pipe_format what
>>> it should have been -- an enum.
>>>
>>> As a result there
On 08.12.2009 15:55, michal wrote:
> This branch simplifies pipe/p_format.h by making enum pipe_format what
> it should have been -- an enum.
>
> As a result there is no extra information encoded in it and one needs to
> use auxiliary/util/u_format.h to get that info instead. Linking to the
> a
Hello,
I'm planning to merge gallium-strict-aliasing branch soon, which will
bring another gallium api change.
pipe_reference function has different arguments, because the old version
was pretty much not really useful for strict-aliasing compliant code
(util_color_pack functions also gets an updat
On 04.12.2009 11:24, Kenneth Graunke wrote:
> On Thursday 03 December 2009 12:47:36 Brian Paul wrote:
> [snip]
>> I've been meaning to go over imports.[ch] and make a bunch of the
>> wrapper functions inlines.
>>
>> A lot of the wrappers aren't needed any more. Back before valgrind I
>> used the m
On 03.12.2009 19:46, Matt Turner wrote:
> Most of the functions in imports.c are very small, to the function
> call overhead is large relative to their size. Can't we do something
> like in the attached patch and move them to imports.h and mark them
> static inline? Things like memcpy and memset ar
On 03.12.2009 20:55, Christoph Bumiller wrote:
> Roland Scheidegger schrieb:
>> Hi,
>>
>> I'm planning to merge gallium-noblocks branch to master soon. This api
>> change may affect your driver, statetracker, whatever. I _should_ have
>> fixed up all in
On 03.12.2009 11:17, Keith Whitwell wrote:
> On Wed, 2009-12-02 at 12:46 -0800, Roland Scheidegger wrote:
>> On 02.12.2009 18:33, José Fonseca wrote:
>>> I've seen strict aliasing assumption causing bugs in other gallium
>>> components. It seems endemic to our code
can fix them I guess it's just a bit
less convenient function, if this is the approach we'll take.
Roland
>
> Jose
>
> From: Roland Scheidegger
> [srol...@vmware.com] Sent: Wednesday, December 02, 2009 23:19 To:
> Jose Fonseca Cc
On 02.12.2009 18:33, José Fonseca wrote:
> I've seen strict aliasing assumption causing bugs in other gallium
> components. It seems endemic to our code. Unless we actively decidee to
> go and chase the strict aliasing bugs now we should add
> -fno-strict-aliasing to all our builds.
Do we ever wa
Hi,
I'm planning to merge gallium-noblocks branch to master soon. This api
change may affect your driver, statetracker, whatever. I _should_ have
fixed up all in tree stuff using it, but that's not a guarantee it will
still run correctly (nv50 driver was strange for instance), and
certainly if you
On 02.12.2009 18:33, José Fonseca wrote:
> I've seen strict aliasing assumption causing bugs in other gallium
> components. It seems endemic to our code. Unless we actively decidee to
> go and chase the strict aliasing bugs now we should add
> -fno-strict-aliasing to all our builds.
Hmm, actually
On 02.12.2009 18:33, José Fonseca wrote:
> On Wed, 2009-12-02 at 09:05 -0800, Roland Scheidegger wrote:
>> Hi,
>>
>> I've come across some bug (which I thought might be related to the
>> gallium-noblocks branch, but it's not) which caused a segfault but only
&g
Hi,
I've come across some bug (which I thought might be related to the
gallium-noblocks branch, but it's not) which caused a segfault but only
when not using debug builds. I think this is the same issue Vinson was
seeing some time ago. Looks like a impossible backtrace:
#0 st_texture_image_copy
On 01.12.2009 15:35, Keith Whitwell wrote:
> On Tue, 2009-12-01 at 06:31 -0800, Roland Scheidegger wrote:
>> On 01.12.2009 11:16, Ian Romanick wrote:
>>> Speaking of which... there are a bunch of conflicts merging 7.7 to
>>> master in Galliumland. Could one of you guys
On 01.12.2009 11:16, Ian Romanick wrote:
> Speaking of which... there are a bunch of conflicts merging 7.7 to
> master in Galliumland. Could one of you guys take a look at it? I have
> no clue what's going on over there.
Quite a few of that was due to the gallium interface changes (introduced
by
On 27.11.2009 19:32, michal wrote:
>> Why is the MAX here smaller than for fragment samplers? Doesn't GL
>> require them to be the same, because GL effectively binds the same set
>> of sampler states in both cases?
>>
>> Can you take a closer look at what the GL state tracker would have to do
>>
Hi,
just a warning I'm planning on merging width0 branch to master tomorrow.
This is a interface change eliminating width/height/depth arrays from
pipe_texture, instead just storing base width/height/depth. In-tree
drivers/state trackers should be fixed (I think though there might be
bugs with rbu
I'm planning to merge st_shader-varients branch to master tomorrow.
This should not adversely affect drivers, unless they rely on generics
inputs/outputs semantic_index always starting at 0 without holes
(something that they shouldn't do but it would have worked previously).
Feedback for hw driver
1 - 100 of 273 matches
Mail list logo
