vehemens wrote:
It appears that the RV250 (ChipID = 0x4966) may also require the
texture unit pair-wise workaround.
That would imho be really strange since the chip physically has only one
tmu per pipe, but who knows...
I found that by enabling the workaround, one of my lockup causes was
elim
vehemens wrote:
Posting my latest DRM and Mesa patches in case they should prove useful to
anyone else. They are to head as of early Saturday.
I moved the CP idle outside the while loop in radeon_state.c. I think it may
apply to the R300 as well as there is an "if R300 idle command" in the
Keith Whitwell wrote:
Right now, I'm primarily concerned with unified memory chipsets, like
i915 and via. This memory manager would be suitable for managing the
AGP memory on non-unified chipsets, but a different implementation
would be needed for the on-card video ram, based more on dma and
copy
Donnie Berkholz wrote:
I recently updated Mesa from 6.4.1 to CVS HEAD, and discovered that the
UT2003 demo [1] didn't work anymore. With some help from aet, I finally
got some useful information out of it that suggests TNL as the likely
culprit:
(gdb) bt
#0 0xb3038ae5 in _mesa_align_free (ptr=0
Keith Whitwell wrote:
You should only be able to get into that stacktrace if you have set
MESA_EXPERIMENTAL in the environment. Is that true? What happens if
you unset it?
No this happens (for me) when MESA_EXPERIMENTAL is not set too, which is
weird and the reason I've filed a bug about it
Brian Paul wrote:
I want to get Mesa 6.5 out this week. Please don't check in any risky
code in the mean time. Bug fixes only. Thanks.
I did check in a slight change to radeon/r200 which might not be
considered a bugfix, but it should be fairly low risk, so I hope that's
ok. (The reason be
Jim Duchek wrote:
Not sure if there's an open bug for this or not. I'm not on this list
-- please CC any comments to me directly.
Jim
Index: radeon_state.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_state.c,v
Brian Paul wrote:
The current Mesa cvs code does not run for me however for direct
rendering, there was a change in dri_util.c (drmClose to drmCloseOnce)
which breaks this for me. I could not find that symbol anywhere even
in current drm cvs.
I believe Keith has fixed this. Can you confirm?
Micha? Król wrote:
Okay, I understand that with this changes I can safely commit the code now.
It looks like your changes broke r200 (supposedly radeon too) vtxfmt
code, at least if there is a fallback to tnl (it works if I use
tcl_mode=1, and some simple progs not causing fallbacks work with
Roland Scheidegger wrote:
Micha? Król wrote:
Okay, I understand that with this changes I can safely commit the code
now.
It looks like your changes broke r200 (supposedly radeon too) vtxfmt
code, at least if there is a fallback to tnl (it works if I use
tcl_mode=1, and some simple progs not
Jaakko Hyvätti wrote:
A' = As + (1 - As) * Ad
R' = As * Rs + (1 - As) * Ad
Example:
As = 0.5
Rs = 0.8
Ad = 0
Rd = 0.2
R' = As * Rs + (1 - As) * Ad = 0.5 * 0.8 + 0.5 * 0.2
Presumably that should be Rd there (and above too)?
= 0.5
This is incorrect, the correct R' is obviously 0.8, becau
Philipp Klaus Krause wrote:
I don't know if Mesa developers are aware of this problem:
amaya, a web browser and html editor from w3c crashes with Mesa software
rendering, but works with DRI enabled or nonfree Nvidia drivers.
Some information can be found at
http://bugs.debian.org/cgi-bin/bugrepor
Lukas Hejtmanek wrote:
On Fri, Apr 21, 2006 at 12:22:56PM -0700, Ian Romanick wrote:
why this extension is not included in i915 driver? I added it to sources,
recompiled and tested with www.glest.org, it seems to be ok, so I think it could
be included into Mesa/src/mesa/drivers/dri/i915/i915_con
Lukas Hejtmanek wrote:
On Thu, May 04, 2006 at 02:15:29PM +0200, Roland Scheidegger wrote:
I'm not sure why you'd need to change the routing of texture coord
sets to the texture interpolators (at least it looks to me this
code does that) for texture_env_crossbar, since fragment pr
A new version of the s3tc library is available, at the usual place,
http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html.
It has a major bug fixed in the fetch texel code.
Thanks to all contributors
Roland
---
Using Tomcat
Ignacio Castaño wrote:
Roland Scheidegger <[EMAIL PROTECTED]> wrote:
A new version of the s3tc library is available, at the usual place,
http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html.
It has a major bug fixed in the fetch texel code.
Have you thought about
Philipp Klaus Krause wrote:
> Ian Romanick wrote:
>
>> That said, there were some patches floating around *years* ago that
>> exposed larger point sizes. I could have sworn that those got
>> committed. Does anyone know the status of those patches?
>
> AFAIR these patches were by Ronald Schneide
Daniel Sperka wrote:
> Can anyone confirm the mesa release required for the glPointSize fixes
> that went in?
large point sizes (unaliased) for r200 went into cvs oct 5 2005 and it
looks like it didn't make it into the mesa 6-4 branch. So you need at
least mesa 6.5.
Roland
Using Tomcat but need
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 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 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 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
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
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:
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
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
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
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
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 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 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 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 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
> ++--
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 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
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 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?
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 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
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 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:
>>>>
>
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 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 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
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
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
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
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
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 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
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 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 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 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 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 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 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,
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
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
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
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
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 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 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 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
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 12.02.2009 06:29, Dave Airlie wrote:
> Hi,
>
> So I have a goal to get a radeon driver that works on a bufmgr and that
> then can be used on non-mm/mm, and also where I can make DRI2 and FBOs
> work.
>
> So with that in mind and not wanting to write this 3 times, I've done a
> major refacto
On 12.02.2009 13:48, Roland Scheidegger wrote:
> On 12.02.2009 06:29, Dave Airlie wrote:
>> Hi,
>>
>> So I have a goal to get a radeon driver that works on a bufmgr and that
>> then can be used on non-mm/mm, and also where I can make DRI2 and FBOs
>> work.
&
On 12.02.2009 15:10, Roland Scheidegger wrote:
> On 12.02.2009 13:48, Roland Scheidegger wrote:
>> On 12.02.2009 06:29, Dave Airlie wrote:
>>> Hi,
>>>
>>> So I have a goal to get a radeon driver that works on a bufmgr and that
>>> then can be used on
On 13.02.2009 16:26, Philipp Klaus Krause wrote:
> Is someone working on implementing this extension in Mesa?
Not sure, but note it's a OGL 3.0 feature so required at some point.
> Which hardware could support it?
Any modern hardware should be able to support it, r300 definitely can
and i965 too (
On 13.02.2009 05:49, Dave Airlie wrote:
>>> Compressed textures also seem to be broken, since they'll raise a FPE:
>>> Program received signal SIGFPE, Arithmetic exception.
>>> [Switching to Thread -1480239424 (LWP 11180)]
>>> 0x9c80da1d in radeon_miptree_create (rmesa=0x9499c48, t=0x9909e80,
>>> t
On 13.03.2009 21:31, Ian Romanick wrote:
> Ian Romanick wrote:
>> Roland Scheidegger wrote:
>>> Module: Mesa
>>> Branch: master
>>> Commit: 114152e068ec919feb0a57a1259c2ada970b9f02
>>> URL:
>>> http://cgit.freedesktop.org/mesa/mesa/commit/?
On 16.03.2009 14:03, Keith Whitwell wrote:
>
>> The only hardware that can support this extension that doesn't already
>> have support for ARB_fragment_shader is G400 and R100. Convince me that
>> we really want to clutter Mesa with shit extensions to add functionality
>> to support 10 year old h
On 16.03.2009 16:37, Chris Rankin wrote:
> --- On Mon, 16/3/09, Roland Scheidegger wrote:
>> you forgot to mention the R200 - not that it makes much difference,
>> and I wouldn't know exactly how to implement this on these chips,
>> though it probably wouldn't be
On 16.03.2009 20:44, Ian Romanick wrote:
> Keith Whitwell wrote:
>>> The only hardware that can support this extension that doesn't already
>>> have support for ARB_fragment_shader is G400 and R100. Convince me that
>>> we really want to clutter Mesa with shit extensions to add functionality
>>> t
Ok, since it looked like there might be people wanting to give this a
look, here's the draft spec of MESA_texture_signed_rgba.
Roland
Name
MESA_texture_signed_rgba
Name Strings
GL_MESA_texture_signed_rgba
Contact
Notice
IP Status
No known IP issues
Status
Version
0.
On 24.03.2009 06:07, Dave Airlie wrote:
> Hey,
>
> So I've been playing with radeon FBOs and have run into a problem with how
> to allow apps to get an FBOs that isn't swrast fallback :-)
>
> radeons can by default render to ARGB, ARGB, RGB565 mostly, now in
> this case when the app ask
On 08.04.2009 22:45, Stephane Marchesin wrote:
> On Wed, Apr 8, 2009 at 21:43, Corbin Simpson
> wrote:
>> Brian Paul wrote:
>>> Denis Martinez wrote:
Hi!
I'm a GSoC student interested in the Gallium subjects
which are about the implementation of VDPAU and OpenGL 3.0.
On 26.04.2009 17:59, martin krastev wrote:
> hello.
>
> I have been experiencing difficulties trying to get fixed-pipeline TCL
> and ARBVP1 hardware support for an ATI 9250 PCI board (chip id 0x5960)
> under Xorg 1.5.3 and FOSS ATI DRI edge 6.10, running on a ppc station.
> Is there such a know is
On 28.04.2009 19:46, martin krastev wrote:
> Thank you, Roland, for the prompt reply.
>
> 'R200_DEBUG=fall' did not reveal any sw fallbacks, so my inital
> assumption of a potential TCL such occuring appears to be wrong. On
> the other hand, 'R200_DEBUG=all' showed something interesting.
> 'R200_
On 29.04.2009 16:12, martin krastev wrote:
> Thank you, Roland, that explains it all. When i said the code was
> running that much faster on almost the same configuration - that other
> config is AGPx4, with a native OSX driver edge for the rv280 (it's a
> mac). And yes, the vertex arrays are large
On 02.05.2009 01:53, Maciej Cencora wrote:
> Hi,
>
> this simple patch fixes (for IGP chips, non IGP aren't affected):
> - 8 piglit tests: general/texgen, glean/texCube, mesa/crossbar, shaders/fp-
> kil, texturing/gen-teximage, texturing/gen-texsubimage, texturing/lodbias,
> texturing/texredefine
On 04.05.2009 17:15, Maciej Cencora wrote:
> On sobota, 2 maja 2009 13:41:54 Maciej Cencora wrote:
>> On sobota, 2 maja 2009 02:50:54 you wrote:
>>> On 02.05.2009 01:53, Maciej Cencora wrote:
Hi,
this simple patch fixes (for IGP chips, non IGP aren't affected):
- 8 piglit tests:
On 17.05.2009 20:27, Corbin Simpson wrote:
> Hate to keep bugging the list, but these things just aren't very
> well-documented sometimes. This is pretty much all
> pipe_rasterizer_state-specific.
>
> First, point_smooth and line_smooth. I've heard that there's ways to
> handle these in vertex
On 16.05.2009 19:24, Maciej Cencora wrote:
> Dnia sobota, 16 maja 2009 o 19:11:43 Maciej Cencora napisał(a):
>> Dnia sobota, 9 maja 2009 o 15:02:56 Maciej Cencora napisał(a):
>>> Hi,
>>>
>>> I'd like to implement ARB_texture_rg support in core mesa and then in
>>> r300 driver.
>>> What files I'd ha
1 - 100 of 273 matches
Mail list logo
