headers
tstellar | 1 Jun 2010 07:41
Picon

[PATCH] r300/compiler: Prevent the fragmentation of TEX blocks in the pair scheduler.

From: Tom Stellard <tstellar <at> gmail.com>

This fixes bug:

https://bugs.freedesktop.org/show_bug.cgi?id=25109
---
 .../dri/r300/compiler/radeon_pair_schedule.c       |   39 +++++++++++++-------
 1 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_pair_schedule.c b/src/mesa/drivers/dri/r300/compiler/radeon_pair_schedule.c
index a279549..0641be5 100644
--- a/src/mesa/drivers/dri/r300/compiler/radeon_pair_schedule.c
+++ b/src/mesa/drivers/dri/r300/compiler/radeon_pair_schedule.c
 <at>  <at>  -208,21 +208,32  <at>  <at>  static void emit_all_tex(struct schedule_state * s, struct rc_instruction * befo

 	assert(s->ReadyTEX);

-	/* Don't let the ready list change under us! */
-	readytex = s->ReadyTEX;
-	s->ReadyTEX = 0;
-
-	/* Node marker for R300 */
-	struct rc_instruction * inst_begin = rc_insert_new_instruction(s->C, before->Prev);
-	inst_begin->U.I.Opcode = RC_OPCODE_BEGIN_TEX;
-
-	/* Link texture instructions back in */
-	while(readytex) {
-		struct schedule_instruction * tex = readytex;
-		readytex = readytex->NextReady;
+	if(s->ReadyTEX){
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Jun 2010 08:45

[Bug 28304] build fails on nouveau_stateobj.h

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

Vinson Lee <vlee <at> vmware.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |NOTABUG

--- Comment #1 from Vinson Lee <vlee <at> vmware.com> 2010-05-31 23:45:01 PDT ---
The Fedora 12 x86_64 workstation is missing the Nouveau header files. They can
be obtained from the libdrm package.

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
Nicolai Haehnle | 1 Jun 2010 12:00
Picon

Re: [PATCH] r300/compiler: Prevent the fragmentation of TEX blocks in the pair scheduler.

This was supposed to go to the mailing list as well... sorry about that *sigh*

On Tue, Jun 1, 2010 at 7:41 AM, tstellar <tstellar <at> gmail.com> wrote:
> From: Tom Stellard <tstellar <at> gmail.com>
>
> This fixes bug:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=25109

Is this really correct? If I understand your patch correctly, what it
does is that TEX instructions that depend on earlier TEX instructions
will be emitted in the same TEX group on R300. So if you have
dependent texture reads like this:

 MOV r0, something;
 TEX r1, r0, ...;
 TEX r2, r1, ...;

You will now emit both TEX in the same TEX indirection block, which I
thought was wrong, because the second TEX instruction will actually
use the contents of r1 *before* the first TEX instruction as
coordinates. At least that's how I thought the TEX hardware works:

1) Fetch all coordinates for all TEX instructions in an indirection block
2) Execute all TEX instructions in parallel
3) Store all results in the respective destination registers

If my understanding is correct, then I believe your change miscompiles
the above shader fragment. Can you clarify this?
(Continue reading)

Permalink | Reply | 1 comment |
headers
bugzilla-daemon | 1 Jun 2010 12:37

[Bug 28304] build fails on nouveau_stateobj.h

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

Kevin Hobbs <hobbsk <at> ohiou.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|NOTABUG                     |

--- Comment #2 from Kevin Hobbs <hobbsk <at> ohiou.edu> 2010-06-01 03:37:29 PDT ---
This workstation does have 

rpm -q libdrm libdrm-devel
libdrm-2.4.18-2.fc12.x86_64
libdrm-2.4.18-2.fc12.i686
libdrm-devel-2.4.18-2.fc12.x86_64

I took a look at /usr/include/nouveau/nouveau_channel.h where nouveau_channel
is defined and there is nothing there called "cur".

The rest of the code around the line that is producing the error refers to
so->cur instead of chan->cur could this be a typo?

As I understand it this build target should not depend on any hardware but
should build software Mesa and OSMesa.

--

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

Permalink | Reply | 0 comments |
headers
Kristian Høgsberg | 1 Jun 2010 14:59
Gravatar

Re: EGL on Windows

On Sun, May 30, 2010 at 10:54 AM, José Fonseca <jfonseca <at> vmware.com> wrote:
> On Sun, 2010-05-30 at 05:55 -0700, Jakob Bornecrantz wrote:
>> On Sat, May 29, 2010 at 9:49 AM, Chia-I Wu <olvaffe <at> gmail.com> wrote:
>> > On Sat, May 29, 2010 at 1:19 AM, Jakob Bornecrantz <wallbraker <at> gmail.com> wrote:
>> >> On Fri, May 28, 2010 at 8:46 AM, Chia-I Wu <olvaffe <at> gmail.com> wrote:
>> >>> I've got access to a Windows machine recently, and I've spent some time today
>> >>> to add GDI backend to st/egl.  The code can be found at
>> >>>  http://cgit.freedesktop.org/~olv/mesa/log/?h=egl-gdi
>> >> Cool stuff! Nice work.
>> > Thanks.
>> >>>
>> >>> The command options I use to build the DLLs are
>> >>>
>> >>>  $ scons statetrackers=egl drivers=softpipe
>> >> You can also crosscompile easily from Linux if you have
>> >> mingw32/mingw-w64 packages installed with scons.
>> > The last time I tried, the cross-compiled DLLs didn't load when I
>> > tried them on a Windows box.  No idea how to investigate that :(
>> >>> The DLLs are able to run the "tiger" demo from the OpenVG reference
>> >>> implementation (after fixing a bug in the demo) on Windows.
>> >>>
>> >>> I will clean up the branch as I find the time.  It is mostly SConscript work.
>> >>> The GDI backend itself is only slightly over 500 lines of code.
>> >> I would recommend breaking out the fixes from the SConscript commits.
>> >> Most of the fixes can probably be brought in directly. Especially the
>> >> "st/vega: Use FREE" commit.
>> > Sure.  I will do that.
>> >
>> > About the portability issues.  I have to do the following
>> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Jun 2010 15:47

[Bug 28304] build fails on nouveau_stateobj.h

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

--- Comment #3 from Vinson Lee <vlee <at> vmware.com> 2010-06-01 06:47:25 PDT ---
Can you try a newer version of the Nouveau headers from libdrm-2.4.18 proper or
later?

The top-of-tree nouveau/nouveau_channel.h has struct nouveau_channel member
cur.

drm: 607e228c263d5d171bd0615d5d93202dda371e5f (master)

nouveau/nouveau_channel.h
    31  struct nouveau_channel {
    32          uint32_t *cur;
    33          uint32_t *end;
    34  
    35          struct nouveau_device *device;
    36          int id;
    37  
    38          struct nouveau_grobj *nullobj;
    39          struct nouveau_grobj *vram;
    40          struct nouveau_grobj *gart;
    41  
    42          void *user_private;
    43          void (*hang_notify)(struct nouveau_channel *);
    44          void (*flush_notify)(struct nouveau_channel *);
    45  
    46          struct nouveau_subchannel subc[8];
    47          unsigned subc_sequence;
    48  };
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Jun 2010 16:52

[Bug 28304] build fails on nouveau_stateobj.h

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

--- Comment #4 from Kevin Hobbs <hobbsk <at> ohiou.edu> 2010-06-01 07:52:42 PDT ---
(In reply to comment #3)
> Can you try a newer version of the Nouveau headers from libdrm-2.4.18 proper or
> later?
> 

Ahhhh I see the libdrm that comes with Fedora 12 is patched to revert this
change.

From the .spec :

# revert nouveau to interface available in F12 kernel
Patch5: nouveau-revert-to-0.0.15.patch

I do not think updateing libdrm will help me test what I want to test which is
the future Mesa software renderer.

I think the only issue left for this bug is that the linux-x86-64 target
shouldn't be building this driver anyway. That's for the linux-dri targets.

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
Joakim Sindholt | 1 Jun 2010 18:08

debug_named_value description

Hi.
I just had a look at debug options in u_debug, specifically enumerated
options in debug_get_flags_option(). It stands out that struct
debug_named_value doesn't have a description field, as is used in r300g.
I'm guessing that for this reason, r300g has it's own system, and I'm
reluctant to use it as well.
It can be quite useful to have a description available; especially when
you have options named "fp", "vp", "cs", "rs", "fb", etc. that aren't
exactly descriptive in their own right (at least for people unfamiliar
with the driver).

Would it be acceptable to add a description field to debug_named_value?

- zhasha
Permalink | Reply | 3 comments |
headers
José Fonseca | 1 Jun 2010 18:24
Favicon

Re: debug_named_value description

On Tue, 2010-06-01 at 09:08 -0700, Joakim Sindholt wrote:
> Hi.
> I just had a look at debug options in u_debug, specifically enumerated
> options in debug_get_flags_option(). It stands out that struct
> debug_named_value doesn't have a description field, as is used in r300g.
> I'm guessing that for this reason, r300g has it's own system, and I'm
> reluctant to use it as well.
> It can be quite useful to have a description available; especially when
> you have options named "fp", "vp", "cs", "rs", "fb", etc. that aren't
> exactly descriptive in their own right (at least for people unfamiliar
> with the driver).
> 
> Would it be acceptable to add a description field to debug_named_value?

I think it might be useful.

Just make sure NULL is valid description and ensure that the existing
code is doesn't break or is fixed.

E.g., add a new DEBUG_NAMED_VALUE_WITH_DESCRIPTION macro and keep
DEBUG_NAMED_VALUE with the same number of args.

Jose
Permalink | Reply | 2 comments |
headers
Joakim Sindholt | 1 Jun 2010 19:46

Re: debug_named_value description

On Tue, 2010-06-01 at 17:24 +0100, José Fonseca wrote:
> On Tue, 2010-06-01 at 09:08 -0700, Joakim Sindholt wrote:
> > Hi.
> > I just had a look at debug options in u_debug, specifically enumerated
> > options in debug_get_flags_option(). It stands out that struct
> > debug_named_value doesn't have a description field, as is used in r300g.
> > I'm guessing that for this reason, r300g has it's own system, and I'm
> > reluctant to use it as well.
> > It can be quite useful to have a description available; especially when
> > you have options named "fp", "vp", "cs", "rs", "fb", etc. that aren't
> > exactly descriptive in their own right (at least for people unfamiliar
> > with the driver).
> > 
> > Would it be acceptable to add a description field to debug_named_value?
> 
> I think it might be useful.
> 
> Just make sure NULL is valid description and ensure that the existing
> code is doesn't break or is fixed.
> 
> E.g., add a new DEBUG_NAMED_VALUE_WITH_DESCRIPTION macro and keep
> DEBUG_NAMED_VALUE with the same number of args.
> 
> Jose
> 

I devised a path that will output something like this:

debug_get_flags_option: help for NINE_DEBUG:
|   lib [0x00000001] Debugging information on library interface
(Continue reading)

Permalink | Reply | 1 comment |

Gmane