mesa3d-dev

Re: [Mesa3d-dev] ARB draw buffers + texenv program

[Dave A. <ai...@gm...>]

>
> (3) Should gl_FragColor be aliased to gl_FragData[0]?
>
>      RESOLUTION: No.  A shader should write either gl_FragColor, or
>      gl_FragData[n], but not both.
>
>      Writing to gl_FragColor will write to all draw buffers specified
>      with DrawBuffersARB.
>
> So I was really just masking the issue with this. From what I can see
> softpipe messes up and I'm not sure where we should be fixing this.
> swrast does okay, its just whether we should be doing something in gallium
> or in the drivers is open.
>
> From what I can see i965 + r300-r500 and at least nv40 from talking to Ben
> would need fragment program changes to emit to each buffer instead.

Okay I'm failing to get this to work, I'll run down the ideas I had so
far that failed.

1. Have the mesa state tracker add the extra output instructions to
the fragment program at compile time. Failed: no where to actually
invalidate the current fragment program.

2. Add a flag to mesa context and have mesa add the extra output
instructions at compile time (prog parser + texenvprogram). Failed: no
where to tell that the FP needs updating has changed so needs to be
recompiled. this works for texenvprog but fails for user programs.

Now the other place to do this is like i965 does, in the driver but
from a gallium pov it seems like something the state tracker should
deal with at TGSI doesn't seem to care about the nuance between
FRAG_OUTPUT_COLOR and FRAG_OUTPUT_DATAx

http://people.freedesktop.org/~airlied/fp-convert-color-data-fail-one.patch

Has the fail for case 2, the programopt.c changes are most likely
correct, and I guess I can do option 1 with some sort of state tracker
program invalidation (i.e. freeing the TGSI tokens and letting it get
recompiled.)

Ideas?

Dave.

Re: [Mesa3d-dev] to Implement on new GPUs

[nitesh s. <nit...@gm...>]

hello all,

thank you for reply

Actually I am working on arm board which support OpenGLES 1.1 and OpenGLES
2.0.
which provides hardware acceleration for redering images.
What my objective is that I want to implement this OpenGLES 2.0 into mesa
for interactive graphics with hardware acceleration to use Mesa in arm board
with this suppurted OpenGLES libraries.

how could I proceed for implement OpenGLES 2.0 in Mesa ?




thanking you
Nitesh Suthar







On Sun, Apr 11, 2010 at 5:14 PM, PLUG GULP <plu...@gm...> wrote:

> On Sat, Apr 10, 2010 at 11:09 AM, nitesh suthar <nit...@gm...>
> wrote:
> > dear all ,
> > Would any one suggest me.
> > How to implement es into new GPU's ?
> >
>
> Please could you elaborate on "implement es into new GPU's"?
>
>
> > thanking you
> > regards
> > Nitesh Suthar
> >
> ------------------------------------------------------------------------------
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Mesa3d-dev mailing list
> > Mes...@li...
> > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> >
> >
>

Re: [Mesa3d-dev] ARB draw buffers + texenv program

[Dave A. <ai...@gm...>]

On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul <br...@vm...> 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 understand the
>> draw buffers. The attached patch fixes it here for me on r300g anyone
>> want to test this on Intel
>> with the piglit test before/after?
>
> The piglit test passes as-is with Mesa/swrast and NVIDIA.
>
> It fails with gallium/softpipe both with and w/out your patch.
>
> I think that your patch is on the right track.  But multiple render targets
> are still a bit of an untested area in the st/mesa code.
>
> One thing: the patch introduces a dependency on buffer state in the
> texenvprogram code so in state.c we should check for the _NEW_BUFFERS flag.
>
> Otherwise, I'd like to debug the softpipe failure a bit further to see
> what's going on.  Perhaps you could hold off on committing this for a bit...

Well Eric pointed out to me the fun line in the spec

(3) Should gl_FragColor be aliased to gl_FragData[0]?

      RESOLUTION: No.  A shader should write either gl_FragColor, or
      gl_FragData[n], but not both.

      Writing to gl_FragColor will write to all draw buffers specified
      with DrawBuffersARB.

So I was really just masking the issue with this. From what I can see
softpipe messes up and I'm not sure where we should be fixing this.
swrast does okay, its just whether we should be doing something in gallium
or in the drivers is open.

>From what I can see i965 + r300-r500 and at least nv40 from talking to Ben
would need fragment program changes to emit to each buffer instead.

Dave.

[Mesa3d-dev] GLES1/2 and DRI drivers

[Kristian H. <kr...@bi...>]

Hi,

I've been looking into the GLES1/2 support in mesa and trying to
figure out how to make it work for DRI drivers as well.  The current
approach only works for gallium, and it works by compiling mesa core
as different state trackers.  Each state tracker is just a thin filter
on top of the public API and in the end, the result is essentially
three copies of the mesa state tracker that all load the same gallium
chipset driver to deal with the hardware.  As far as I understand it,
anyway.

I would like to propose that we structure the code a bit differently,
specifically I would like to see a way where we can load one DRI
driver which can implement multiple GL APIs.  I understand that
gallium was designed to support mulitple APIs, however, in the case of
gl/gles1/gles2, there is a big overlap, and we can support all three
without different state trackers.

Specifically, what I'm thinking of is

 - the dri driver gets a new entry point that lets us create a context
for a specified API (along these lines:
http://cgit.freedesktop.org/~krh/mesa/commit/?h=gles2&id=707ad2057e5a2ab2e5fa36be77de373ed98967c5)

 - mesa core becomes multi api aware, struct gl_context gets a new API field

 - move the es entry points from src/mesa/es into src/mesa/main

 - create src/gles1 and src/gles2 directories for compiling
libGLESv1.so and libGLESv2.so; basically glapi-es2 as a shared object
file.

Obviously, we should keep the option to compile mesa state tracker as
gles1 or gles2 only for example (to allow building a small gles2-only
dri driver and to keep the current gallium setup working).

This is all still work in progress for me, but I'm curious what people
think of this approach.

Thanks,
Kristian

[Mesa3d-dev] [Bug 27586] texture3d max sizes are too small

[<bug...@fr...>]

https://bugs.freedesktop.org/show_bug.cgi?id=27586

Alex Deucher <ag...@ya...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Drivers/DRI/R600            |Mesa core
         AssignedTo|dri...@li...urceforge |mes...@li...urceforg
                   |.net                        |e.net

--- Comment #1 from Alex Deucher <ag...@ya...> 2010-04-12 07:20:10 PDT ---
The max texture sizes are 8192 on r6xx/r7xx hardware, however, the driver is
currently only 4096 due to limitations in core mesa.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 26123] Rendering to offscreen depth-texture fails

[<bug...@fr...>]

https://bugs.freedesktop.org/show_bug.cgi?id=26123

Marek Olšák <ma...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Drivers/DRI/r300            |Mesa core
         AssignedTo|dri...@li...urceforge |mes...@li...urceforg
                   |.net                        |e.net

--- Comment #5 from Marek Olšák <ma...@gm...> 2010-04-11 19:55:17 PDT ---
The demo more or less works here with latest kernel and libdrm (2.6.32 is too
old), but I think Mesa doesn't like the way shadow samplers are used here as it
fails with gallium/softpipe too. I am changing the component to Mesa core.

In the meantime, please use the sampler type sampler2DShadow and the fetching
function shadow2D. That should work.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [PATCH] softpipe: Fix division by zero

[Arpad B. <arp...@go...>]

Sorry about my last mail which was empty except for the attached patch.
The patch fixes a division by zero crash which is triggered when I run 
the cairo test-suite using its gl backend and the gallium softpipe driver.
The test-suite still crashes when I'm using llvmpipe, need to look into 
that.

[Mesa3d-dev] (no subject)

[Arpad B. <arp...@go...>]

Re: [Mesa3d-dev] to Implement on new GPUs

[PLUG G. <plu...@gm...>]

On Sat, Apr 10, 2010 at 11:09 AM, nitesh suthar <nit...@gm...> wrote:
> dear all ,
> Would any one suggest me.
> How to implement es into new GPU's ?
>

Please could you elaborate on "implement es into new GPU's"?


> thanking you
> regards
> Nitesh Suthar
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>

Re: [Mesa3d-dev] r300g: hack around issue with doom3 and 0 stride

[Luca B. <lu...@lu...>]

> r300g: hack around issue with doom3 and 0 stride

> This is most likely a bug in the mesa state tracker, but do the quick hack
> for now to avoid the divide by 0.

This is not a bug: stride 0 means that the vertex attribute is
constant for all vertices.

It is not a special value either: advancing the vertex attribute
pointer by 0 will naturally result in always fetching the same value.

Thus, the patch is not likely to be correct: you should instead either
program stride 0 to the hardware if supported, or fetch the vertex
attribute with the CPU (I think it is always in a user buffer, but not
sure, maybe OpenGL allows explicitly specifying a VBO with stride 0)
and use whatever means Radeon provides to set a constant vertex
attribute (e.g. nVidia GPUs have a FIFO method exactly for that).

Re: [Mesa3d-dev] gallium-resources branch merge

[Keith W. <kei...@go...>]

On Sat, Apr 10, 2010 at 4:52 PM, Roland Scheidegger <sr...@vm...> wrote:
> On 10.04.2010 17:10, Keith Whitwell wrote:
>> On Sat, Apr 10, 2010 at 4:05 PM, Keith Whitwell
>> <kei...@go...> wrote:
>>> On Sat, Apr 10, 2010 at 3:49 PM, Roland Scheidegger <sr...@vm...> wrote:
>>>> On 10.04.2010 16:43, Chia-I Wu wrote:
>>>>> On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell
>>>>> <kei...@go...> 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 commits in gallium-resources and
>>>>> merge the new branch to master?
>>>> I've never used git rebase -i but I'm not convinced that can give
>>>> something sensible. It wasn't done strictly by components, with a couple
>>>> merges from master (and gallium-buffer-usage-cleanup) in between and
>>>> fixes for already converted things...
>>>>
>>> Squash merge it is.
>>
>> Somewhat arbitrary decision to avoid stretching this out any further.
>>
>> I don't think the history that was on the branch was very useful, nor
>> does inventing history seem likely to help people searching for
>> regressions, etc.  The branch is effectively an atomic change, so
>> let's deal with it like that...
>
> Yeah, you're right. Thinking about it, parts of it were always broken
> throughout the life of the branch or didn't even build, so squash merge
> makes sense. Glad it's merged - no more conflicts fixing for merges from
> master :-).

Indeed.

Keith

Re: [Mesa3d-dev] gallium-resources branch merge

[Roland S. <sr...@vm...>]

On 10.04.2010 17:10, Keith Whitwell wrote:
> On Sat, Apr 10, 2010 at 4:05 PM, Keith Whitwell
> <kei...@go...> wrote:
>> On Sat, Apr 10, 2010 at 3:49 PM, Roland Scheidegger <sr...@vm...> wrote:
>>> On 10.04.2010 16:43, Chia-I Wu wrote:
>>>> On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell
>>>> <kei...@go...> 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 commits in gallium-resources and
>>>> merge the new branch to master?
>>> I've never used git rebase -i but I'm not convinced that can give
>>> something sensible. It wasn't done strictly by components, with a couple
>>> merges from master (and gallium-buffer-usage-cleanup) in between and
>>> fixes for already converted things...
>>>
>> Squash merge it is.
> 
> Somewhat arbitrary decision to avoid stretching this out any further.
> 
> I don't think the history that was on the branch was very useful, nor
> does inventing history seem likely to help people searching for
> regressions, etc.  The branch is effectively an atomic change, so
> let's deal with it like that...

Yeah, you're right. Thinking about it, parts of it were always broken
throughout the life of the branch or didn't even build, so squash merge
makes sense. Glad it's merged - no more conflicts fixing for merges from
master :-).

Roland

Re: [Mesa3d-dev] [PATCH] Provide dri shared library building and SDK installation.

[Keith W. <kei...@go...>]

I haven't been following this very closely, so apologies if I'm going
over established ground.

This patch appears to create new libraries from some subset of Mesa's
internals.  At a guess you're selecting some internal interface(s)
within mesa to become the public API of those libraries?  I'm pretty
sure that's not something we're trying to achieve in this project.

We have public APIs which we respect and implement, and which are
maintained and evolved under the Khronos umbrella.

We have a strong driver-level interface (ie gallium) which we benefit
greatly from being rev as fast and as hard as we can, to adapt to our
evolving understanding of the problem space.  We really don't want to
subject that interface to the strictures that come with becoming a
public API or ABI.

We have a third interface, the Mesa driver interface, which may appear
relatively stable, but which is more accurately described as
neglected, veering towards deprecated.  The shortcomings of this
interface, in particular its porous nature and inappropriate
abstraction level, were major catalysts provoking the development of
gallium.  Those shortcomings would also make it less than appropriate
as a public API.  At some point in the future, that interface will
either roar back into rapid evolution or truly be deprecated in favour
of either gallium or a low-level, legacy-free GL3/4 subset from
Khronos.

I can't easily tell from your patch what interfaces these new
libraries have, or what expectations there would be for maintaining
compatibility on those interfaces going forward.  I'd like to see that
spelled out explicitly.  Without investigating further, I can say I'm
not aware of any interface within Mesa which we'd be happy to promote
to a public interface, nor one which we'd be happy to accept extra
restrictions on in terms of compatibility.

Keith

On Fri, Apr 9, 2010 at 11:59 PM, Luc Verhaegen <li...@sk...> wrote:
> Patch cherry-picked from my dri-sdk-7.8 branch against current head
> (edb5253dfa). An earlier full build through of all drivers (except
> nouveau, i will play with its expansive libdrm dependencies later)
> showed it to be an exact match still.
>
> This patch, while not harming or hampering anything or anyone, gives us
> the ability to maintain and build DRI drivers out of tree for those so
> inclined. Build system additions only. No adverse effects. Everybody
> wins.
>
> I intend to provide changes as needed, I hope to at least manage to
> maintain released versions in the long term.
>
> For those wanting a test run, please check out the 7.8 version of the
> SDK and the drivers in my cgit.freedesktop.org repos.
>
> Luc Verhaegen.
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>

Re: [Mesa3d-dev] gallium-resources branch merge

[Keith W. <kei...@go...>]

On Sat, Apr 10, 2010 at 4:05 PM, Keith Whitwell
<kei...@go...> wrote:
> On Sat, Apr 10, 2010 at 3:49 PM, Roland Scheidegger <sr...@vm...> wrote:
>> On 10.04.2010 16:43, Chia-I Wu wrote:
>>> On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell
>>> <kei...@go...> 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 commits in gallium-resources and
>>> merge the new branch to master?
>>
>> I've never used git rebase -i but I'm not convinced that can give
>> something sensible. It wasn't done strictly by components, with a couple
>> merges from master (and gallium-buffer-usage-cleanup) in between and
>> fixes for already converted things...
>>
>
> Squash merge it is.

Somewhat arbitrary decision to avoid stretching this out any further.

I don't think the history that was on the branch was very useful, nor
does inventing history seem likely to help people searching for
regressions, etc.  The branch is effectively an atomic change, so
let's deal with it like that...

Keith

Re: [Mesa3d-dev] gallium-resources branch merge

[Keith W. <kei...@go...>]

On Sat, Apr 10, 2010 at 3:49 PM, Roland Scheidegger <sr...@vm...> wrote:
> On 10.04.2010 16:43, Chia-I Wu wrote:
>> On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell
>> <kei...@go...> 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 commits in gallium-resources and
>> merge the new branch to master?
>
> I've never used git rebase -i but I'm not convinced that can give
> something sensible. It wasn't done strictly by components, with a couple
> merges from master (and gallium-buffer-usage-cleanup) in between and
> fixes for already converted things...
>

Squash merge it is.

Keith

Re: [Mesa3d-dev] [Mesa-dev] Mesa dev list has been moved to fd.o

[Dan N. <dbn...@gm...>]

On Sat, Apr 10, 2010 at 6:38 AM, Brian Paul <br...@vm...> wrote:
> Thanks to Tollef and Jesse, everyone should now be subscribed to the mesa-dev list at freedesktop.org.  You should see this message twice if you're on the new list.
>
> I'll probably shut down the old list next week when I get back from a little time off...

Are mesa3d-announce or mesa3d-user moving? I'm just asking because I'm
going let the gmane people know to change the address.

--
Dan

Re: [Mesa3d-dev] gallium-resources branch merge

[Roland S. <sr...@vm...>]

On 10.04.2010 16:43, Chia-I Wu wrote:
> On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell
> <kei...@go...> 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 commits in gallium-resources and
> merge the new branch to master?

I've never used git rebase -i but I'm not convinced that can give
something sensible. It wasn't done strictly by components, with a couple
merges from master (and gallium-buffer-usage-cleanup) in between and
fixes for already converted things...

Roland

Re: [Mesa3d-dev] gallium-resources branch merge

[Chia-I Wu <ol...@gm...>]

On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell
<kei...@go...> 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 commits in gallium-resources and
merge the new branch to master?

-- 
ol...@Lu...

Re: [Mesa3d-dev] gallium-resources branch merge

[Roland S. <sr...@vm...>]

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

[Mesa3d-dev] Mesa dev list has been moved to fd.o

[Brian P. <br...@vm...>]

Thanks to Tollef and Jesse, everyone should now be subscribed to the mesa-dev list at freedesktop.org.  You should see this message twice if you're on the new list.

I'll probably shut down the old list next week when I get back from a little time off...

-Brian

Re: [Mesa3d-dev] gallium-resources branch merge

[Keith W. <kei...@go...>]

Hmm, not sure whether to merge or squash-merge this branch.  Any thoughts?

Keith

Re: [Mesa3d-dev] gallium-resources branch merge

[Keith W. <kei...@go...>]

On Sat, Apr 10, 2010 at 12:39 PM, Keith Whitwell
<kei...@go...> wrote:
> On Sat, Apr 10, 2010 at 12:36 PM, Keith Whitwell
> <kei...@go...> wrote:
>> On Sat, Apr 10, 2010 at 6:59 AM, Chia-I Wu <ol...@gm...> wrote:
>>> On Fri, Apr 9, 2010 at 9:07 PM, Keith Whitwell <ke...@vm...> wrote:
>>>> On Fri, 2010-04-09 at 03:43 -0700, Keith Whitwell wrote:
>>>>> On Thu, 2010-04-08 at 15:20 -0700, Marek Olšák wrote:
>>>>> > On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell <ke...@vm...>
>>>>> > wrote:
>>>>> >
>>>>> >         OK, it seems like quite a few cases had migrated to the new
>>>>> >
>>>>> >         buffer_map_range() behaviour.  I've looked at all I can find
>>>>> >         and moved
>>>>> >         them back to the old behaviour.
>>>>> >
>>>>> >         glean is passing now on softpipe.
>>>>> >
>>>>> > There's now an assertion failure in pipe_buffer_flush_mapped_range.
>>>>> > Given a mapped range, the current behavior in debug build doesn't
>>>>> > allow to flush its subrange if it doesn't touch the last byte of the
>>>>> > range. The attached patch fixes that and changes u_uploadmgr for the
>>>>> > mapped and flushed ranges to match. Please review.
>>>>> >
>>>>> > Other than that, it's stable as master. Thank you very much.
>>>>>
>>>>> OK, if nobody chimes in, let's look at merging this to master in the
>>>>> next day or so.
>>>>>
>>>>
>>>> I've made a final merge of master into gallium-resources.  Please try it
>>>> out and report/fix any issues.  This will be merged tomorrow.
>>> Texturing in i915g seems to be broken.  You can find screenshots of drawpix and
>>> teapot in the attachments.  Any idea?
>>>
>>
>> Looks like only the first row of texels is being uploaded.
>>
>> Maybe stride is being set to zero in the transfer creation, or similar?
>
> Hmm, yes - u_default_get_transfer doesn't fill stride in, which is
> fine for buffers but busted for textures.  I'll modify the two places
> where this is being used for textures.
>
> Keith
>

OK, I've pushed something which should fix this.  Anything more we can
resolve on master.

Keith

Re: [Mesa3d-dev] gallium-resources branch merge

[Keith W. <kei...@go...>]

On Sat, Apr 10, 2010 at 12:36 PM, Keith Whitwell
<kei...@go...> wrote:
> On Sat, Apr 10, 2010 at 6:59 AM, Chia-I Wu <ol...@gm...> wrote:
>> On Fri, Apr 9, 2010 at 9:07 PM, Keith Whitwell <ke...@vm...> wrote:
>>> On Fri, 2010-04-09 at 03:43 -0700, Keith Whitwell wrote:
>>>> On Thu, 2010-04-08 at 15:20 -0700, Marek Olšák wrote:
>>>> > On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell <ke...@vm...>
>>>> > wrote:
>>>> >
>>>> >         OK, it seems like quite a few cases had migrated to the new
>>>> >
>>>> >         buffer_map_range() behaviour.  I've looked at all I can find
>>>> >         and moved
>>>> >         them back to the old behaviour.
>>>> >
>>>> >         glean is passing now on softpipe.
>>>> >
>>>> > There's now an assertion failure in pipe_buffer_flush_mapped_range.
>>>> > Given a mapped range, the current behavior in debug build doesn't
>>>> > allow to flush its subrange if it doesn't touch the last byte of the
>>>> > range. The attached patch fixes that and changes u_uploadmgr for the
>>>> > mapped and flushed ranges to match. Please review.
>>>> >
>>>> > Other than that, it's stable as master. Thank you very much.
>>>>
>>>> OK, if nobody chimes in, let's look at merging this to master in the
>>>> next day or so.
>>>>
>>>
>>> I've made a final merge of master into gallium-resources.  Please try it
>>> out and report/fix any issues.  This will be merged tomorrow.
>> Texturing in i915g seems to be broken.  You can find screenshots of drawpix and
>> teapot in the attachments.  Any idea?
>>
>
> Looks like only the first row of texels is being uploaded.
>
> Maybe stride is being set to zero in the transfer creation, or similar?

Hmm, yes - u_default_get_transfer doesn't fill stride in, which is
fine for buffers but busted for textures.  I'll modify the two places
where this is being used for textures.

Keith

Re: [Mesa3d-dev] gallium-resources branch merge

[Keith W. <kei...@go...>]

On Sat, Apr 10, 2010 at 6:59 AM, Chia-I Wu <ol...@gm...> wrote:
> On Fri, Apr 9, 2010 at 9:07 PM, Keith Whitwell <ke...@vm...> wrote:
>> On Fri, 2010-04-09 at 03:43 -0700, Keith Whitwell wrote:
>>> On Thu, 2010-04-08 at 15:20 -0700, Marek Olšák wrote:
>>> > On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell <ke...@vm...>
>>> > wrote:
>>> >
>>> >         OK, it seems like quite a few cases had migrated to the new
>>> >
>>> >         buffer_map_range() behaviour.  I've looked at all I can find
>>> >         and moved
>>> >         them back to the old behaviour.
>>> >
>>> >         glean is passing now on softpipe.
>>> >
>>> > There's now an assertion failure in pipe_buffer_flush_mapped_range.
>>> > Given a mapped range, the current behavior in debug build doesn't
>>> > allow to flush its subrange if it doesn't touch the last byte of the
>>> > range. The attached patch fixes that and changes u_uploadmgr for the
>>> > mapped and flushed ranges to match. Please review.
>>> >
>>> > Other than that, it's stable as master. Thank you very much.
>>>
>>> OK, if nobody chimes in, let's look at merging this to master in the
>>> next day or so.
>>>
>>
>> I've made a final merge of master into gallium-resources.  Please try it
>> out and report/fix any issues.  This will be merged tomorrow.
> Texturing in i915g seems to be broken.  You can find screenshots of drawpix and
> teapot in the attachments.  Any idea?
>

Looks like only the first row of texels is being uploaded.

Maybe stride is being set to zero in the transfer creation, or similar?

Keith

[Mesa3d-dev] to Implement on new GPUs

[nitesh s. <nit...@gm...>]

dear all ,

Would any one suggest me.
How to implement es into new GPU's ?


thanking you
regards
Nitesh Suthar