Setting isolation level at database level
There are better ways to handle this than dirty reads.  READ UNCOMMITTED queries will still block DDL, like TRUNCATE TABLE, DROP TABLE and ALTER TABLE … SWITCH, so it might not even help.

First, of course, is RCSI which is the basic correct solution for concurrently loading and reading from a database (even a Data Warehouse).  It does not unnecessarily slow down your loads.  It does what is necessary to enable concurrent readers and writers.  And RCSI only creates row versions for UPDATE and DELETE.  INSERT does not generate row versions unless the table has a trigger.

Second, if you want to reload the data warehouse while reports are running READ UNCOMMITTED, they will get wrong results.  So you might as well just KILL the connected sessions, or have your ETL job alter database current set single_user with rollback immediate.

Third, you can use a Database Snapshot to keep the DW available for reads while you are performing ETL.  You can additionally use the snapshot to roll back (restore) a failed ETL process even if it didn't run in a single transaction.